Perrin Harkins wrote: > > On Mon, 10 Jun 2002, I wrote: > > >>In the filesystem. Directly requested .tt files are all sent to a >>default template handler: > > Those are both interesting and may be the most appropriate solution for > the problems you're working on, but I wouldn't call either of them MVC. > You are going straight to a view (template) and letting it drive all > the decisions. In an MVC application, you would go to a controller that > would do some work and then decide which view to show.
I have three kinds of templates: controller entry stubs - called directly to invoke a controller view pages - called by controllers to display results stand-alone dynamic pages - called directly, may not invoke controller I would agree with you if my entry stubs did more than call up the controller, but those templates are simple one-liners that do nothing else. Once the controller has been called it takes over, processing request data, calling models, selecting views, etc. The only influence a stub template has on the view is that of defining the URL that the controller inherits (plus optional parameters as shown in my earlier message). Yes, a developer could make a mess of things by trying to put more stuff into a controller entry stub. We all seem to agree that any scheme can be polluted by poor discipline, and the arrangement I have described is as prone to abuse as any other. Still, I don't think that replacing this: <Location /search> SetHandler perl-script PerlHandler Controller::Search </Location> with this: [% Ctrl.Search() %] makes Controller::Search any less a controller. I could enforce the separation of controller entry stubs from stand-alone templates and view templates by using additional file extensions and handlers, but no one has abused the system as it is so I'm erring on the side of my own laziness. Using the entry stub templates is handy because I don't need to mangle the server configuration to make controllers available from other locations (which means I can stay at the pub while others toil away). Obviously, the stand-alone dynamic pages are not MVC at all. They exist because there are often 'glue' pages that don't warrant the comlexity of MVC (those that don't need M and have very simple VC needs). It is much more convenient to code such pages in the same environment as the MVC stuff (that is, using the same globally defined variables, macros, etc.). -jh
