A modern Perl repalcement for Apache Server Side Includes?

[punch_card_don]

Mammalian Monks,

Yet another website redesign project. This time you're given an old, static website. It has zero dynamic content. This is a brochure website whose only purpose is information delivery. That said, there are a lot of pages, a lot of sections and sub-sections, and four levels of navigation.

Every page has the same header, navigation bar and footer. So, the old website was done in shtml with server side includes on a linux/Apache box. The SSI inserts common header, nav bar and footer code. Plus, calls to external stylesheets. This way, each page file is really just the content with ssi calls, stylesheet calls, and minimal markup. Practically a templating system.

So now you're doing a complete re-design. Graphics, check. Probably going to a jQuery nav bar. And reducing content mark-up to bare bones semantics with as full CSS styling as possible.

But what do you recommend in terms of architecture?

This does not warrant the full MySQL/Template Toolkit treatment. But you'd think that in the last X years something better than SSI would have come along in the world of Perl.

A framework like Dancer? Is this not still overkill? Mojolicious? Even more so.

Or go the full CMS route - Galileo? (Even though cms is not a design spec, and this would be delivering way beyond the project scope.)

I guess the question is - is there a Perl-ish equivalent to the biblical simplicity of good old SSI these days? Something that would complete the separation of content and template, without going overboard.

Thanks.

[CountZero]

Keep it static. No need to burden the server for nothing.

But do write all the pages in Template::Toolkit (taking advantage of all the fetaures of TT) and then have the templating system churn out (off-line) all the pages and put these on the server.

Delivery will be as fast as can be.

[moritz]

If SSI are enough, stick to SSI.

However for my stuff I didn't quite like SSI, and I wrote my own generator for static websites, which has some features that make nested menus (and opening those that lead to the current page) easier.

I don't think it's worth using a framework like Mojolicious or Dancer for static pages.

[skx]

I took wrote my own static-site generator, using HTML::Template, called Templer. It allows plugins for handling breadcrumbs, etc, but largely gets out of the way.

It had never occurred to me to upload such an application to CPAN, but having seen yours I think that might be a plan.

[Anonymous Monk]

It had never occurred to me to upload such an application to CPAN, but having seen yours I think that might be a plan.

Upload, you're in good company

• ttree / Template::Tutorial::Web ,
• tt2size / Template::TT2Site,
• MasonX::StaticBuilder,
• staticvolt / StaticVolt,
• Orze - Another static website generator
• - Another static website generator
• wallflower - Turn your Plack app into a static site
• Miril::Manual - Why and how to use Miril, the static content management sytem.
• Web::Scaffold - build minimalist fancy web sites
• Contenticious - build web sites from markdown
• hid / HiD - Static website publishing framework
• Zucchini / zucchini - script to generate and upload template based websites

[punch_card_don]

You know, I'm leaning towards not fixing what's not broken. It might not be hip or sexy, but for this application SSI has much to recommend it.
• Zero learning curve
• already installed, ready to go, proven, stable
• No more resource hungry than a templating system
• While it does use resources each page serve, this is a low-traffic site on a private server that won't even notice the minor load
• Although it is static, the content and the nav bar do change from time to time. An off-line generator would mean having to re-generate the entire website each time any page was updated, adding steps of complexity in a a situation where pages may be edited by multiple authors who have limited web skills to being with. Or I have to develop an interface for that function too. Whereas with SSI, edit the file directly once, and that's it, done.
• same for the nav bar, which changes occasionally;

[sundialsvc4]

Elaborating slightly on what has already been said ... I would use Template::Toolkit in a stand-alone script to efficiently generate the various content elements ... producing as an output a set of HTML-files etc. that can then be served statically.

There are many ways (SQLite, XML, or even a CSV file output from a spreadsheet) to specify the content and the desired taxonomy of that content.   The Perl script could efficiently generate side-bars pointing to other linked content as needed.   But when all it said and done, you’re going to the command-line and typing, say, ./generate_my_site and in a matter of a few seconds the entire set of files has been generated, from whence Apache can now do what Apache does best.   Furthermore, if you plan carefully, none of the existing bookmarks that folks are using now, wherever they might be, need be disturbed:   you can generate the same output-file names as before.

This will achieve a very efficient make-over of the site, to the extent that the Perl script avoids redundant human effort while boosting consistency.   It is also relatively cheap, and a lot can be accomplished in just a few days.   (I did this sort of project six or seven times just last year.)

When there is a bona-fide need for some non-static content, then you can begin to wedge-in some Perl code (or what-have-you) in order to serve those specific areas.   By once again using the same templates (and/or some other templates that, perhaps, have also been statically-generated by the aforementioned script), the look-and-feel of the completed site is seamless and whole.   The user might not have any way to tell what content is static and what is dynamic.

[Your Mother]

There is this: Plack::Middleware::SSI. I've used it be able to run a dev environment on plack that is deployed on apache for production.

[stonecolddevin]

varnish allows you to use ESI, which is like SSI on steroids.