I've said it before... :) http://mathforum.org/epigone/modperl/zhixswahar/v04210105b76eecf6c2be@%5b192.168.1.3%5d
Rob On Sat, Nov 16, 2002 at 10:33:44PM +0100, Thomas Klausner wrote: > 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$_.$/}
