A simpler TemplateLoader would be helpful.
One approach I've used to simplify it is to override all loading by creating an object that extends the freemarker.template.Configuration and override this method: Template getTemplate(final String name, Locale locale, Object customLookupCondition, String encoding, boolean parseAsFTL, boolean ignoreMissing) The method to override has changed a little over time and I don't think it is meant to be used this way, but all other Configuration.getTemplate() methods call this method so it is an easy way to override all Template loading (assuming you are doing your own caching and so on, which is part of what I wanted in this case, ie use a managed cache external to FreeMarker that other things also use instead of the cache internal to FreeMarker). Hopefully this is helpful feedback, ie the need for and one approach I've found to a simple override for all Template loading. -David On Jan 24 2017, at 4:28 am, Daniel Dekany <[email protected]> wrote: > Tuesday, January 24, 2017, 6:27:38 AM, Roberto Benitez wrote: > > > I am working on a TemplateLoader implementation that loads from a > database. From a previous e-mail with Daniel Dekany, he mentioned > that this is something you still need, and may be interested in integrating. > I have the source code on github: > rbenitez22/freemarker-datasource-loader > > > | | > rbenitez22/freemarker-datasource-loader > | | > > Your link above didn't go through in one piece somehow, so again: https://github.com/rbenitez22/freemarker-datasource-loader (To clone: https://github.com/rbenitez22/freemarker-datasource-loader.git) > > > This is something I am still tweaking as I learn more about the > inner workings of the frame work. Let me know if you have further > thoughts on what could be modified to make it integrate better. > > The TemplateLoader interface have some tricky aspects, so reading the JavaDoc carefully is important. (It took a while for me to figure all details out too, but then I have JavaDoc-ed them.) Especially look into how a templateSource works (the return value of findTemplate). In your case I think it should just be the things that you are using in the SQL `where`: name and locale. And note that it must implement `equals` (and `hash`) properly. > > Also, I hope that freemarker-datasource-loader can be simplified over time, so it doesn't employ this many interfaces/classes. > > My main problem with FreeMarker's TemplateLoader interface is that it assumes that you execute existence check, last modification query, and loading 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. > > > \--Roberto > > \-- Thanks, Daniel Dekany
