Now this mechanism is working in FM3. At the end I did this: http://freemarker.org/builds/fm3/api/freemarker-core/org/apache/freemarker/core/templateresolver/TemplateResolver.html
Explanation: If you implement a custom TemplateResolver, then you are required to declare which of the Configuration settings you support, out of those that are related to template loading/caching. Then the user just sets those setting on the Configuration-level, pretty much like in FM2 (except that in FM3 you set settings in a Configuration.Builder object, not directly in the Configuration). DefaultTemplateResolver is not treated specially, it works just like any custom TemplateResolver; you are allowed to set Configuration.templateLoader, Configuration.templateUpdateDellayMilliseconds, etc. because DefaultTemplateResolver happens to support them. If Configuration.templateLoader is set to `new MyTemplateResolver()`, and MyTemplateResolver only cares about templateUpdateDellayMilliseconds, but can't use the TemplateLoader abstraction of FM, then the user can set templateUpdateDellayMilliseconds as usual, but can't set Configuration.templateLoader (they get an exception that tells they that MyTemplateResolver doesn't support the templateLoader setting). The author of a custom TemplateResolver admittedly has to face some extra complexity here, but I believe it's not a big deal in practice. Also, very few developers will ever implement a custom TemplateResolver. This thing is optimized for the users who just configure FreeMarker. Any insights? Like as a reality check, how well would this work with Moqui? Thursday, February 16, 2017, 6:33:01 PM, David E Jones wrote: > On Thu, 2017-02-16 at 15:56 +0100, Daniel Dekany wrote: >> Thursday, February 16, 2017, 6:17:00 AM, David E Jones wrote: >> >> > >> > This is cleaner, more obvious what's going on underneath, but since >> > the DefaultTemplateResolver will be the most commonly used you >> > could just leave the current setting methods as they are and just >> > document that if you set a different TemplateResolver they will be >> > ignored. >> >> Or they should just throw exception if the template resolver set is >> not the default one. It can be quite annoying when someone sets the >> templateUpdateDelay for example and it has silently no effect. > > Good idea, I was thinking more of calls before setting a TemplateResolver. > >> Also, it's maybe quite speculative, but perhaps some custom >> TemplateResolver have some of the standard settings, like for example >> the templateUpdateDelayMilliseconds. Then it's somewhat confusing that >> cfg.setTemplateUpdateDelayMilliseconds doesn't work, while >> myResolver.setTemplateUpdateDelayMilliseconds does. So I guess if we >> keep those setters in the Configuration, then they should forward to >> the templateResolver, if it implements the interface that contains the >> setter. > > It isn't too cumbersome to have extra methods to implement, but > would be nice to have those methods with a default implementation > that throws the appropriate Exception. In Java 8 you can do this > with default methods on the interface, but in Java 7- this could > simply be an abstract class to have the same effect. > > -David -- Thanks, Daniel Dekany
