Hi Jesse, > It's the "addition tricks" which bug me out. With those two words you > establish the mother of all slippery slopes to architecture oblivion. When > you have objects passing freely between your "Controller" and "View" (which > are quoted here, 'cuz I don't think they are separate in this case), how do > you decide where to put a particular bit of code? The answer is, it is > completely arbitrary.
First of all, I don't do it that way. I pass simple Perl data structures to Template Toolkit, because I know what data I want to send and it's faster that way. However, I don't really understand your objection. The view doesn't get to do anything but call accessor methods on the object. They look just like simple structures: NAME: [% person.name %] The template coder doesn't know that "person" is an object and TT called a method to get that instead of just doing a hash lookup. The reason people usually do this is so they can do lazy-loading. With something like Class::DBI you can set it so that if no one ever uses person.name in a template it will never be loaded from the database. It's a performance optimization. People who like that approach have objected to my approach of passing data because it requires the controller to know exactly what data the template will need, or else pass data that may not be needed and possible waste effort. Personally, I don't mind having the controller know what data is needed, as long as it doesn't make any decisions about how the data is shown. > In the architecture you describe it is inevitable that given enough time and > different programmers your "Controller" and "View" will coalesce into a > undifferentiated mash of code and HTML, separated only by the fact that they > are in two different files. I don't see where you're getting this from. The objects return data, not HTML, and they have no side effects. They are read-only. The view (template) does all of the formatting. > IMHO, any system built on Template Toolkit (unless it is small and always > managed by the same programmer) will ultimately devolve in just the same way > as a Server Page system. Well, you're not right about that. We built a very large system at eToys using TT and it never had any of these problems you're describing. The separation was clear, and the templates did nothing but display data. > HTML::Template isn't just faster than just about > everything else out there -- it also is pretty much the only templating > system which has an actual clear vision when it comes to how it fits into > the larger architecture. I don't agree with that either. Template Toolkit and AxKit (or any other XSLT-based system) can both enforce a clear separation of responsibilities. Template Toolkit allows people to do it other ways if they want to, through the use of plugins or by passing objects that do more than just return data, but the documentation and most of the mailing list discussion centers around the same approach as HTML::Template. The speed differences aren't really significant at this point. All of these tools are blazing fast. They all have C code under the hood now (with the new HTML::Template compiler). The bottleneck on performance of web applications is still what it always was: data access. - Perrin
