Thursday, February 16, 2017, 5: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.
I would clarify there that it's the build() method that throws the exception. Because we don't want to constraint the order in which you set the settings. Like maybe you set the templateLoader on the builder, and only then set the TemplateLoader to MyTemplateResolver that doesn't support a templateLoader. >> 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. Yes, that looks to be the simplest solution. (Even if not the cleanest... that would be introducing interfaces like HasTemplateLoaderSetting, and so you can detect this capability without "probing" the setter methods. Certainly an overkill anyway.) > -David > > -- Thanks, Daniel Dekany
