> I fear that in real-life this will create confusing hard-to-read > perlscripts. If you have a big project with 50 different types of > pages you need to implement 50 queries in one script or create 50 > different scripts. Somehow it seems to me that it would be a good idea > to have the queries in the templates.
The actual architecture of your site depends on your requirements. We have indeed (nearly) one perl module for every single page there is in the system. However, there are in fact big advantages for us to make it so 'complicated' Take a look at these: http://www.e-sixt.com/cgi-perl/rental/or?tset=de http://www.e-sixt.com/cgi-perl/rental/or?tset=common/db http://www.e-sixt.com/cgi-perl/rental/or?tset=common/ba If I had DBI Calls in the three template sets de, common/db, and common/ba and I'd need to change the DBI call a little, I'd have to do it three times. But I only need to do it once, because one and the same template within the set is always linked to the same perl module that does the DBI stuff. Obviously, you could argue that I could do the DBI stuff in one INCLUDEd template, accessible to all tsets. This is true but I as a programmer prefer writing in Perl, rather than in TT :-) I maintain Perl stuff and our screendesigners maintain HTML stuff, ie templates. So the separation of concerns goes further than just the system itself. It makes separation of development work possible too. _______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
