In case you have missed it in the other thread, note that it seems that there won't be a new alternative TemplateLoader interface in FM2, so this will have to be solved with the existing TemplateLoader there.
-- Thanks, Daniel Dekany Wednesday, January 25, 2017, 4:17:10 AM, Roberto Benitez wrote: >>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 > > > >
