Hi! On Sat, Nov 16, 2002 at 03:31:39PM -0500, Perrin Harkins wrote: > >I also posted this on perlmonks: > >http://www.perlmonks.org/index.pl?node_id=213300 > > Ovid on Perlmonks already said some of the things I would have said > about needing a presentation language. For a templating system to be > useful, it has to be able to deal with loops and conditionals. Your > system pushes those into the Perl code, splitting the presentation > control into multiple places. This fails one of my major goals: the > template coders should be able to change the presentation without help > from a Perl coder. What if they decide they don't want to loop through > the links, but rather just print a message saying there are some? What > if they only want to show the first two? What if they want to display a > list with commas between the elements where they didn't use a separator > before? A mature templating system can handle all of these issues > without changing the main Perl module code.
That's a very good point I didn't really think about. I was thinking of templates as DUMB frontends that should just display data. Period. Thinking of them as tools that handle presentation logic (as Ovid pointed out) seems to make more sense. It does pay of to write RFCs before starting to code... > >Because IMO, the main reason for using templates is to seperate code > >from markup. > > It sounds to me like you want one of the HTML attribute ones, like Petal > or HTML::Seamstress. What was wrong with those? One problem I see with HTML::Seamstress is that it uses the HTML attributes 'class' and 'id' for templating info. But those attributes are used by CSS and JavaScript and might conflict somehow. I do not know if you can change the behaviour of HTML::Seamstress to use other attributes, though. But this stopped my from looking further. And I didn't look at Petal. For now. > >There is one module, CGI::FastTemplate, that does seperate code from > >markup completly. But the way different templates are strung together > >seems rather comlicated to me. > > It's not complicated, but it is somewhat confusing the first time you > look at it. I don't find your approach much easier though. Well, I found mine easier :-) (But I guess this is the reason for the Template Flood on CPAN - everbody finds his own solution easier...) > Isn't your fill method just doing a sort of multi-level join here? All > of the data is passed in already, so there is no reason to delay > evaluation of the templates. The main reason for doing this was to simplify testing. I planned to just test the plain data structures, that should be free of HTML at this time (before the fill). This (testing) was in fact the reason I started thinking about this proposal in the first place. > More importantly, your use of AUTOLOAD to treat method calls as file > names looks neat, but is not a good approach. It's limiting (all > templates in one directory!) and has potential security issues with > namespace clashes. These are all just the same method call with a > single argument changed, so why not write them that way? I planned to handle those namespace and filename issues. > .. > force you to use them. They are flexible modules. I think you should > look at them more closely before you go off on your own. That's what I'll do. Thanks for the excellent feedback. -- #!/usr/bin/perl http://domm.zsi.at for(ref(bless[],just'another'perl'hacker)){s-:+-$"-g&&print$_.$/}
