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.

/J\

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

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

Mark Stosberg

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,
    }
  }
};
[download]


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%]
[download]


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%],[%key:if.lt:value%],[%key:if.gt: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.

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.

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.

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.