http://www.perlmonks.org?node_id=236169

Everytime someone announces their own pet templating project we advocate our favorite set of templating solutions. However, I find myself in the situation where I have to do exactly that.

My reasoning

Basically put, I'm the one of programmers in a web team of 6. The other guy sticks to ASP on win32 and is not interested in much else. The skills of our team revolve around Dreamweaver and after much patience, SSI has finally been fully understood by everyone.

I've had a set of very good chats with my line manager and I've got support for a more dynamic site and to use a full templating solution. This will mean I'll also be spending time writing a common API to perform simple data fetch tasks.

So far so good and in a pure Perl environment I'd be using the Template Toolkit (and I have in a previous project). But with the relative skills of the team in mind, I've been thinking that I can't really expect the team to learn more than one templating language. We maintain corporate content in ASP, Java, Jython, PHP and Perl (yay) and I'm stuck for a templating solution.

Currently I use Velocity, Smarty, XML/XSLT, HTML::Template and the Template::Toolkit (my personal favorite). I also do all the hard template bits rather than programming while someone watches.

For obvious reasons I want to consolidate these (keeping XML/XSLT as a suitable second when I need it). I also want to be able to give power to the content authors without me having to write all their templates for them while they watch - I don't have the time.

My *possible* solution

Based on the above and my previous experience of porting HTML::Template to other languages, it seems a natural choice. After all, I have successfully ported it to Java and VBScript.

Thinking about it though, I find that I've got to add in a whole new set of directives for handling API calls (that I create) as well as integrating with any XML processor.

Whilst this doesn't bother me it does leave me to wonder whether I should just start from scratch and release the same templating engine in all 4-6 languages or build on HTML::Template as I have indicated.

If I did the latter, I would certainly do this in my spare time so that I could release this solution into the public domain but then we have YATS (yet another templating solution).

So what do people think? Have you been in a similar situation and how did you solve it? Do you think modification and release of an existing module (say HTML::Template::Alternate) is a reasonable thing to do?

Thanks for reading if you made it this far!

SP
  • Comment on OT: Templating solutions - cross language rfc

Replies are listed 'Best First'.
Re: OT: Templating solutions - cross language rfc
by joe++ (Friar) on Feb 18, 2003 at 10:25 UTC
    How about Cocoon/Axkit?

    Switching to Cocoon for your web application environment may be way off, but the following got my attention...

    Thinking about it though, I find that I've got to add in a whole new set of directives for handling API calls (that I create) as well as integrating with any XML processor.
    ...for what the cocoon project calls "logic sheets" or "taglibs": pre-defined functions done in xml, which may then be included in any source document (xml) by inserting a specific "tag".

    The advantage is full separation of content, presentation and logic and using standards (xml and xslt in this case).

    Besides Cocoon you may want to look into AxKit, similar structure but all done under mod_perl. Perl.com has a good article about using your own taglibs with axkit.

    --
    Cheers, Joe

Re: OT: Templating solutions - cross language rfc
by knowmad (Monk) on Feb 18, 2003 at 14:11 UTC

    Since you are looking for possible ideas, you may want to look into the TAL project created by the Zope team. It provides an unique alternative to the custom HTML tag solution.

    Jean-Michel Hiver has ported TAL to Perl in the guise of Petal. There has been some some discussion on the list of porting it to other languages such as Java. From my limited testing, the TAL format cooperates well with GUI editors like Dreamweaver (unlike other template solutions such as Text::Template).

    Good luck and please report back on what you eventually decide to use.

Re: OT: Templating solutions - cross language rfc
by tmiklas (Hermit) on Feb 18, 2003 at 08:48 UTC
    I thik it's a good thing to have some choice between availble solutions. I use a templating system written by a friend of mine. He gave it a name and we are using it for about 2 years.
    Yes - it's Yet Another Templating System - but it's the simpliest one i've ever seen and does my job perfectly! Anyway - it's not on CPAN (yet), becous it's not ready for it. I'd like to add some improvements before making it public.

    Anyway the most important thing is what you really need and you should focus on that. On the other side porting Template::Toolkit to other languages also seams reasonable - especially becouse it's good for the community (Perl and others as well).

    ++
    Greetz, Tom.
Re: OT: Templating solutions - cross language rfc
by Aristotle (Chancellor) on Feb 18, 2003 at 18:23 UTC
    I prefer Template::Toolkit over anything else these days, but if crosslanguage (and possibly -platform) is such a concern, I don't believe anything can beat XML. Just about every language under the sun (no pun intended) has one or more libraries for it these days. Obviously their APIs will vary, but XPath, XSL and friends are standard and very powerful; sticking to them will minimize the amount of heterogenia between the sources in various languages.

    Makeshifts last the longest.

Re: OT: Templating solutions - cross language rfc
by perrin (Chancellor) on Feb 18, 2003 at 20:41 UTC
    Don't write a new one. If you really need something that has identical syntax and abilities in multiple languages, go with XSL. You can make it behave somewhat like HTML::Template if you try. Maintaining your own templating system in 4 languages (or even 3, if you start by porting an existing one) is hopeless. It's guaranteed to be lacking in features compared to the other choices.