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

Reply via email to