> How do you solve the DBI-thing ? I am planning to use the toolkit in ... > Why do you consider DBI an no-no anyway ?
It's not DBI in general, it's use of the TT DBI plugin. (Note: This all my opinion. An opinion I'd be surprised to find unechoed, but still an opinion) Determining what data to pull from a database, and the code to actually pull it is a programming decision. I place that code into the perl code that calls my template, and simple pass data (usually an arrayref of hashrefs that are my results) to the template. Deciding how to display that data is up to the template. If I have some database calls that are not dependent on the calling code (say, general site navigation), then that code will be reused, so I'll put it in a plugin. This means the code to query the database is in one spot, and the code to display the results is in another. Either of these can change without affecting the other (as long as the same interface between them is maintained, that is, the template variables) DBI in templates is ugly, and destroys the whole point (IMHO). It belongs in the perl code, either calling or plugin. -- SwiftOne [EMAIL PROTECTED] _______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
