|
in reply to Re: Template modules, logic, and SOC
in thread Template modules, logic, and SOC
I should mention how I came up with the name Template::Recall for the module. Perrin Harkins dubbed Mason (PHP/JSP fit this bill) styled template systems as "callback" and TT2, HTML::Template systems as "pipeline".
Template::Recall really works like the "callback" model, except in reverse. Perl isn't inserted between sections of the code and "called back" to by the template; instead, the template is (effectively) inserted between blocks of Perl code, and it is "called back" to. This is why it only requires substitution, and no logic.
|
Re^3: Template modules, logic, and SOC
by perrin (Chancellor) on Jan 23, 2008 at 20:06 UTC
|
Sorry, this is just another pipeline module in my opinion. Callback means that the template is in charge of the program flow. In your case, the perl code calls the template and passes in data, thus pipeline.
Frankly, there's nothing new under the sun with templating. What you've done is pretty much identical to several modules that have been on CPAN for years, like CGI::FastTemplate. In fact, there's no reason you can't use HTML::Template, Text::Template, TT2, etc. in the way you're showing here.
I think you'll find that substitutions are really not enough. You at least need conditionals, because some things are too small to make a whole separate template and put the conditional in the perl code. And loops make for much more readable HTML code, which is one of the major reasons to use a template. And whitespace control is important. And formatting all of your numbers and dates in perl before you call the template gets ugly when you start needing the same data in multiple formats. And putting all this into your perl code means any significant HTML change has to be done by a perl programmer, which is fine for some dev teams and not for others.
My advice is to get over your idea that the view shouldn't contain logic. It's supposed to contain logic -- logic about how to display the data. It may sometimes be convenient to write the view logic in perl, and sometimes in a view-specific shorthand like TT2. | [reply] |
|
|
Frankly, there's nothing new under the sun with templating. What you've done is pretty much identical to several modules that have been on CPAN for years, like CGI::FastTemplate.
Actually, I was aware that CGI::FastTemplate existed, and it was the only one I could see that worked "identically" to Template::Recall when I submitted to CPAN. It just seemed that CGI::FastTemplate existed in the wrong namespace for a general purpose (perhaps non- web-based) template system, and besides, it hasn't been updated since 1999.
In fact, there's no reason you can't use HTML::Template, Text::Template, TT2, etc. in the way you're showing here
Sure. All template systems essentially share the same goal. But there is one definite benefit that I can think of for using Template::Recall over these, at least for simple loops. I mention this in my introduction, regarding an output of row data to a simple table like that in my writeup. Using a pipeline system, you have to iterate over the data twice to output the table. Once when generating the array of hashes, and then again as (say) HTML::Template renders it against <TMPL_LOOP> on the call to print $template->output();. With Template::Recall (and Mason/PHP/JSP), there is no such cost, because you can output the row as soon as you receive it. Template::Recall just does it through a method call, which in my opinion, is cleaner.
My advice is to get over your idea that the view shouldn't contain logic. It's supposed to contain logic -- logic about how to display the data. It may sometimes be convenient to write the view logic in perl, and sometimes in a view-specific shorthand like TT2.
Actually, I've never held the opinion that the view should contain no logic. Substitution in my mind is effectively a part of logic. I just want to put as little logic as possible in the template. You're right, sometimes it may be better to have logic in the templates, for instance where you have a team of advanced designers, but there are plenty of other times where projects are driven by people who prefer to do as much in Perl as possible.
| [reply]
[d/l]
[select] |
Re^3: Template modules, logic, and SOC
by Joost (Canon) on Jan 23, 2008 at 19:58 UTC
|
Don't get me wrong, I kind of like the system you described, for a templating system :-).
One of the problems I can see, though, is that for some kinds of output you'll either end up writing "one-off" callbacks, which means you'll now have highly integrated code and template fragments that you'll need to keep in sync spread over multiple files.
In those cases, you may be better off either writing a function that just returns the complete HTML fragment, or putting the formatting details in code in the template directly, just to make it clear what's going on.
| [reply] |
|
|
you'll... end up writing "one-off" callbacks
Yeah, I can see this happening. There was once or twice while working on Sylbi where it seemed like a waste to call a template because the section I was rendering was so small. Of course, you can stuff template sections in __DATA__...
| [reply]
[d/l] |
|
|
