Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Yet Another Templating System

by ruzam (Curate)
on Apr 28, 2006 at 03:59 UTC ( #546176=perlmeditation: print w/replies, xml ) Need Help??

OK, judging from quotes sprinkled liberally, writing a Perl templating system appears to be a rite of passage. It also appears that there is some aversion to yet another templating system.

So I guess like those who came before me I've rolled my own templating system. Mostly because that's just the kind of guy I am, partly because I wanted to create an application that didn't rely on additonal modules. I've seen how HTML::Template works, but I think my design has more to offer (of course I would say that).

I have working code, but it's largely dependent on the application using it. So I guess I'm wondering if it's worth taking the time to pull it out and package it up as a module for Perl community. Or for that matter would anyone be interested in looking at the code to offer suggestions?

Replies are listed 'Best First'.
Re: Yet Another Templating System
by gellyfish (Monsignor) on Apr 28, 2006 at 07:55 UTC

    Whilst not entirely awash with various templating modules, CPAN probably does have enough to have covered most people's requirements. I would suggest that you set out what you think are your systems unique selling points, specifically in comparison with the existing toolkits, including but not limited to Template and HTML::Template: you will find a number of articles here that engage the differences between the available modules and their particular benefits.

    In the end it might be better, rather than putting yet another templating module on the CPAN, to work with the authors of the templating module you feel is closest to what you have done in order to provide the features you feel are missing.


    (has never felt the need to create a templating system in Perl)

Re: Yet Another Templating System
by perrin (Chancellor) on Apr 28, 2006 at 17:21 UTC
    Write your own. Write 12 of them. Post some code here and get some feedback. You'll learn a lot. Just don't put it on CPAN. There are over 100 templating modules there already, and several of them are very good.

    Incidentally, how did writing your own allow you to "create an application that didn't rely on additonal modules"? Isn't your code a module?

      By relying on additional modules I meant relying on modules outside of my application (or at the very least the standard Perl modules without resorting to installing new ones). Of course that argument would fly out the window if I submitted to CPAN :)

      Thanks everyone for your comments!

      I'm pretty sure CPAN isn't ready for YATS at the moment.
        Assuming that licensing is not an issue, you can just bundle and deliver the "outside" modules as part of your application.

        If licensing is issue, you could probably easily deploy the select group of CPAN modules you want to use as distinct and differently-licensed bundle of software.

        See also: A Vision for Easy Web Application Deployment for Perl

Re: Yet Another Templating System
by tinita (Parson) on Apr 28, 2006 at 09:08 UTC
    well, show it =)
    and give the reasons why you needed it.

    i wrote a templating system, too (still in development, but working pretty well); but it works with HTML::Template files, so one side of it is not new, which is maybe the reason why i'm still alive.
    for creating a new templating mini-language and a new module for it you have to have enough good reasons to be accepted.

      OK, well, as I suspected there's definitely strong opinions associated with template systems.

      Here's what I've got going then.

      The basic premise is that the main Perl code is going to do all the work of preparing the data. The template system is simply a means to put it into the page. To that end I guess my style most closely matches Template-Toolkit, even down to the use of '[%' and '%]' which we both seem to have chosen independantly, go figure. I didn't want to take HTML::Template's approach of wrapping things up in tags (that are easily lost in the rest of the HTML, not to mention harder to search for and just plain wordy)

      A $session object is created (my session object does all the usual session management stuff, config files, login, session verification, etc). The $session is used by the page script, which then stuffs it full of what ever data it digs up, in what ever format it needs to be stored as. At the end of the script the $session object is passed into the template processing to generate the page.

      A simple session data example might look like this:
      $session = { data1 => 'test1', # scalar data2 => ['array0', 'array1'], # array ref data3 => { # hash ref data1 => 'test4', data2 => ['array50', 'array51'], data3 => { data_x => 'data2_array_count', data_y => 2, } } };

      A simple template to display this sesion might look like this:
      data1: [%data1%]<br> data2: <br> [%data2:%] &nbsp; [%$_%]<br> [%:data2%] data3: <br> [%data3:%] &nbsp; data1: [%$_.data1%]<br> &nbsp; data2: <br> [%$_.data2:%] &nbsp;&nbsp; [%$_%]<br> [%:$_.data2%] &nbsp; data3: <br> [%$_.data3:%] &nbsp;&nbsp; data_x: [%$_.data_x%] data_y: [%$_.data_y%]<br> [%:$_data3%] [%:data3%] [%data4:%] There's nothing in this data and the entire block will simply be left +out of the output. [%:data4%] Here's a direct reference to a nested key<br> data2 array count is: [%data3.data3.data_y%]<br> <br> Since data_x and data_y are unique here's another way to get to them:< +br> [%data3.data3:%] data_x: [%data_x%]<br> data_y: [%data_y%]<br> [%:data3.data3%] <br> And yet another:<br> [%data3:%] data_x: [%$_.data3.data_x%]<br> data_y: [%$_.data3.data_y%]<br> [%:data3%]

      The key points are:
      - CGI->header() takes care of wrapping the template inside a body
      - Every substitution is enclosed by [% %]
      - Substitution key relates directly to the key/value pairs in $session
      - Nested levels can be reached prefixing the key path to the level ie [%level1key.level2key.level3key%]
      (Of course this presumes that you can't have a '.' in a key name to do this)
      - A block starts when the substitution key ends with a ':', the block ends with the first matching key that starts with a ':'
      - Inside a block, something magic happens. A symolic key '$_' takes on a reference to the value of the block key. If the value is a hash, $_ becomes a reference to that hash. If the value is an array, then the block is repeated for each item in the array with $_ becoming a reference to each item in turn.
      - In addition to the symbolic '$_' key, there's also a symbolic '$i' key which holds the value of the current array index (of an array block).
      - keys are searched first at the top most level, then at the block level (if your keys are unique, you can skip the '$_.' prefix inside blocks)
      - Any value (block) not found or defined is simply left out

      This is the short version. I also have several other macros in my template to do other things:
      [%value:template%] - include another template named 'value'
      (anyplace you can put a 'value' in a macro, you can also use 'key.var' to use the value of a key instead)
      [%key:ift%] something [%key:else%] something else [%:key] - if 'true' else conditions (else is optional)
      [%key:iff%] - Same as 'ift', only if 'false'
      [%key:ifeq:value%],[%key:iflt:value%],[%key:ifgt:value%] - comparison tests, same as 'ift' (string)
      [%key:if.eq:value%],[],[] - comparison tests, same as 'ift' (numeric)
      [%key:table:cols][%key:row%][%key:col%][%key:cell%][%:key%] - given an array, turn it into a table with 'cols' columns. row, col and cell are all optional (the <table> tag itself is supplied by the template)

      I've tried to keep the template substitution as close to the source Perl data as possible and streamlined for most common usage. It's not very pretty to look at, but it's logical and precise (imho) for a Perl developer. I have a school admin application I'm working on that neatly displays a very complex schedule table with a very minimal template.

      I guess I should also add that this is part of a larger 'web application framework' I'm working on, so I've also built in support for template stylesheet themes, icon/image paths, javascript libraries, template view levels, and multi-language directories.

      So, does it warrent further discussion or should I just keep it to myself?
        Everything you've said so far is covered by Template Toolkit, albeit with minor syntax adjustments. You could even modify the TT syntax to parse your template if you wanted to. That would be a very interesting learning experience in writing parser grammars.
Re: Yet Another Templating System
by stonecolddevin (Parson) on Apr 28, 2006 at 05:07 UTC
    show us whatcha got! i sure wouldn't mind looking at it/trying it out
Re: Yet Another Templating System
by spiritway (Vicar) on Apr 28, 2006 at 16:49 UTC

    I don't know about rites of passage, but IMSHO, you should generally ask yourself a couple of questions before undertaking something like this. 1) Is there a need for it? Is something lacking in Perl and CPAN, that makes this necessary and useful? 2) Is there something that comes close, that you could perhaps work with the original programmer/maintainer/whoever, and add to it?

    Reinventing the wheel is fine, if you want to learn how something is done, to see what the issues were in solving the problem. But you're very unlikely to produce, say, a sort routine that will be an improvement on what's already out there. Same thing with templates. They've been around long enough, and have had enough eyes looking for bugs, testing them, etc., that it's not likely you'll come up with anything better. Maybe you would - it could happen. But the odds are against you.

    I suggest you think about your own experiences, and times you thought, "If only they had X, it would be so much easier". Then find out if X exists, and if not, make it.

Re: Yet Another Templating System
by shenme (Priest) on Apr 28, 2006 at 17:20 UTC
    Write the README file and post it here. Just that for now.

    Of course, one of the most interesting parts of the README will be the section describing and illustrating why/how your system is both different from and better than other templating systems. And when it would be advisable to use it and when not.

    If after writing the README you still think it's a better system, by all means post it here. Then if the negafabulatorists don't succeed in depressing you about your system, *then* you can do the rest of the work to publish.

Re: Yet Another Templating System
by Anonymous Monk on Apr 28, 2006 at 08:17 UTC
    put it away. please.

    I've seen a lot of home-rolled templating systems, and none of them come even close to The Template Toolkit, most of them were quite frankly awful and became a maintainence nightmare by the time I'd arrived to work on them - sounds like you've created just such a monster to make life miserable for whoever comes into your business.

    A better plan would be to see how much work it would be to take the unique elements or bespoke bits of your templating system and provide them as a plugin for TT so that you don't have a nightmare legacy for the next 5 to 10 years that holds back your company and causes people to quit.

    In case it hasn't become clear yet, I've left jobs because people thought they could build a better PHP, ASP, TT and failed. In every case they struggled to maintain, document and extend their systems and fell behind as staff struggled to learn it and left or became unproductive as they tried to make it handle new requirements.

      Your absolutly right! Template Toolkit is the best thing ever made and no one will *EVER* make a better one. And since Template Toolkit arrived by virgin birth we know that no *home rolled* templating system will *EVER* be better than it. I'm sure in 60 years I'll still be using Template Toolkit because it's simply the most amazing and powerfull template system ever built by man. Its amazing design means that it will be able to handle any task ever presented to any template system ever for all time!

      /me goes to finish working on his plugin to make Template Toolkit order lunch.

      Eric Hodges

        What are the odds that someone with the explicit design goal of avoiding any non-core modules will write a templating system half as capable as the Template Toolkit in less than a year?

        In my opinion, they're negligable.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://546176]
Approved by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2023-06-10 15:40 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (39 votes). Check out past polls.