Chris Josephes writes: >On 15 Oct 2002, William R Ward wrote: > >> For me, it's because TT allows Perl to be embedded in the template. >> That way lies madness. The advantage of a templating system is that >> you can leave the template maintenance to someone who doesn't know >> programming, and let the programmer focus on the logic. If logic gets >> mixed in with markup, then you might as well not be using here >> documents. > >TT allows Perl to be embedded in a template (through the [% perl %] block, >but doesn't necessarily mandate it or rely on it like other systems. >Text::UberText could just as easily have a module created that allowed for >perl code inclusion, and someone could easily write one for >HTML::Template.
It's too much of a temptation to allow for Perl code inclusion, in my book. People tend to take shortcuts if they're given. >I think that debate has been covered well in the O'Reilly Network article >that Leon Brocard mentioned earlier in the thread >(http://www.perl.com/pub/a/2001/08/21/templating.html) I haven't seen that yet, I'll give it a read... >I'm not a fan of inline code myself, but I don't want to restrict users >either. It's not my desire to keep someone from shooting themselves in >the foot. I don't want to restrict Perl programmers. I want to restrict the number of things that an HTML designer has to know to update the template. >The one argument I will make against inline code is that is limits the >template application to the perl language. HTML::Template has a parser >written in Java, and it's not inconceivable that TT or UT could have >parsers written in Java or Python sometime down the road. That was one of >the reasons I didn't want perl syntax creeping into the UT grammar. That's another good reason... --Bill. -- William R Ward [EMAIL PROTECTED] http://www.wards.net/~bill/ ----------------------------------------------------------------------------- Consistency is not really a human trait. --Maude (from the film "Harold & Maude")
