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
