Tuesday, January 24, 2017, 6:48:16 PM, David E Jones wrote: > 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,
It's not designed for that for sure. (When it comes to widely used libraries like FreeMarker, I'm in camp who wants every class to only have methods that are either final or abstract, and maybe protected. That is, something is either designed to be overridden, or can't be overridden.) > 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). That's another thing I definitely want to solve in FM3 (I'm not sure if I want to go into that in FM2 though), but by providing a setting like cfg.templateResolver (TemplateResolver interface), which has some minimalistic "give me a template like this somehow" method, and default implementation that delegates to TemplateCache. > 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 > -- Thanks, Daniel Dekany
