>Also, I hope that freemarker-datasource-loader can be simplified over >time, so it doesn't employ this many interfaces/classes. Currently, the only essential classes are: 1)JdbcMetaData --A central place to store DB table/column names. 2) TemplateSourceDao --to perform the JDBC/CRUD work 3) DataSourceTemplateLoader -- the loader implementation. 4) (Maybe)?) JdbcTemplateSource -- template data record including the template content itself. This should be helpful to a client such that no additional work should be necessary (in most general cases) to maintain the templates (name/content)--the DAO and JdbcTemplateSource will do the work.
I am experimenting with the other classes/interfaces. In particular, TemplateName and TemplateSource (which extends TemplateName). The idea is to describe template metadata that is more abstract that is more abstract than File, such that it could describe a File or some database record--with the relevant data such as name, locale. BUT, as you noted, necessitates pre-fetching data. >My main problem with FreeMarker's TemplateLoader interface is that it >assumes that you execute existence check, last modification query, and >oading the actual content as 3 separate steps. While that fits how >you deal with plain files (and I guess that's what it was modelled >after), it doesn't fit how you do things with a database. In a >straightforward implementation we would have 3 SQL round trips per new >template loaded, and 2 for each up-to-date checks later. In a smarter >implementation, and as you did it too, you can reduce the number of >SQL operations be prefetching data into the templateSource object >during the existence check (i.e., in findTemplateSource). As >closeTemplateSource will be called pretty soon anyway, working from a >such "cache" is certainly fine (because closeTemplateSource will >invalidate it). But I don't think that you should prefetch the >template content there, because then that will be an unnecessarily >prefetched for template cache up-to-date checks, which is the dominant >TemplateLoader usage in many applications. So it's sill 2 SQL-s per >new template loaded, and 1 per template cache up-to-date checks. >Certainly not a problem in most apps, but it's still bugs me. In >FreeMarker 3 I definitely want to fix this be radically changing the >TemplateLoader interface, and it's also possible that I will backport >that solution into FreeMarker 2 (if people here will agree), though >there it will co-exists with the traditional TemplateLoader, probably >under the name TemplateLoader2 or something, so it's kind of messy. Would the changes to the TemplateLoader be that drastic? Sometimes it is feasible to deprecate old/non-conformant methods (perhaps provide defaults that rely on the new methods), which can later be removed completely. --Roberto
