Hey Jeff & Perrin -- > HTML::Template requires you to pass a perl data structure. Template > Toolkit can handle objects as well (i.e. automatically call their > accessor methods to fetch properties). Passing perl structs > is faster, > while passing objects allows for some additional tricks
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. 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. Sooner or later someone will "get smart" and move what little code remains in the "Controller" into the "View", and get rid of the Controller altogether. Now you're back to square one -- old school "CGI script"-style web apps, a la 1996! 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. 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. > > does the Model returned data contain lots of > > style hints? Or do you leave this completely to the View layer? > > Ideally you should have no style information at all in the model. Absolutely. The Model really just features functions and methods. Does localtime() provide "style hints"? Of course not. Neither should anything which is designed to be a "Model" function. > >>Optimally, the View avoids *ALL* application logic. > > > > mmmm - so the Model has to say RED rather than ERROR? > > Just the opposite: the model provides the list of errors, and > the view > knows how to display them. I think the Model methods would throw exceptions like any normal programming interface. How those exceptions are relayed to the View (e.g., "list of errors", "Internal Server Error", etc.) is the job of the Controller. > > > Sounds like Controller only interacts with one Model? > > The model might be made up of dozens of different classes, but it's > still referred to as "the model" as in "the application's data model." To further elucidate -- the Controller would not dynamically select a different Model depending on what it is doing, as it may select a different View depending on what it is asked to do. Unless it does. :-) Warmest regards, -Jesse- Jesse Erlbaum, CTO Vanguard Media http://www.vm.com 212.242.5317 x115 [EMAIL PROTECTED]
