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?
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)
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.
That doesn't exactly defend to Anonymous Monks rant. Maybe it is justified and maybe its not. Maybe this guys template system is great, maybe it sucks. To just bash him like that and say that all the systems he had seen in the past, so all the ones he will see in the future will suck too, is just crazy so I felt like having a little laugh. Don't crush new peoples dreams just because you've never seen anyone do what they want to do succesfully. We can dream a little can't we? And realistic dreams arn't near as much fun are they?
___________
Eric Hodges
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.
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%]
data2:
[%data2:%] [%$_%]
[%:data2%] data3:
[%data3:%] data1: [%$_.data1%]
data2:
[%$_.data2:%] [%$_%]
[%:$_.data2%] data3:
[%$_.data3:%] data_x: [%$_.data_x%] data_y: [%$_.data_y%]
[%:$_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
data2 array count is: [%data3.data3.data_y%]
Since data_x and data_y are unique here's another way to get to them:
[%data3.data3:%] data_x: [%data_x%]
data_y: [%data_y%]
[%:data3.data3%]
And yet another:
[%data3:%] data_x: [%$_.data3.data_x%]
data_y: [%$_.data3.data_y%]
[%: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%],[%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?
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.
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?
Thanks everyone for your comments!
I'm pretty sure CPAN isn't ready for YATS at the moment.
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
That's pretty much where I'm heading. Self install Perl web apps that you simply place in your CGI directory, click and go. PHP'rs do it all the time. The code is bundled up with the CGI install script, which gets neatly extracted into the correct directories based on the running CGI env and help from the user. I see no reason why Perl can't do the same, provided you're not tied down to installing 3rd party modules in places the user doesn't have access to (or at the very least the self install could check for required modules and inform the user of what's missing).
BikeNomad had the right idea with the Self-extracting Perl archives code he posted (although I'm not sure why he felt the need to encode it).