On Tue, 2017-01-24 at 23:47 +0100, Daniel Dekany wrote:
>
> Should the TemplateResolver-s (the work name for the new interface)
> still get the template name already resolved to absolute and
> normalized? So when cfg.getTemplate is called, then it invokes
> cfg.templateNameFormat.normalizeAbsoluteName(String) to normalize the
> path, and only then it calls the TemplateResolver. Also #import and
> such currently calls templateNameFormat.toAbsoluteName(String,
> String), and that would happen earlier than TemplateResolver is
> involved.
>
> And how would it look... perhaps like this:
>
> public interface TemplateResolver {
>
> Template getTemplate(String templatePath, Local lookupLocale, Object
> customLookupCondition)
> throws IOException;
>
> }
>
> You may notice that it misses the `encoding` and `parsed` parameter of
> cfg.getTemplate. That's because I belive that in FM3 we should not
> allow specifying those as getTemplate parameters anymore, but that
> will be another thread when we get there.
IMO it should pass through the exact text from the include/etc in the template.
It might be worth constraining to a valid URI syntax
but other than that a TemplateResolver would be much more flexible if no
normalization/etc is done.
Passing in the Locale rather than trying to call it multiple times with
different locale extensions is a good idea too as different
underlying content or file stores may have their own approach for this. For
example a JCR back end has quite a bit for meta data and
content variations.
In general more parameters and less built into the path/name is a good thing
IMO.
-David
