Tuesday, February 7, 2017, 7:40:18 AM, David E Jones wrote:
> 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.
In FM2 there's a class like this:
public abstract class TemplateNameFormat {
...
abstract String toAbsoluteName(String baseName, String targetName) throws
MalformedTemplateNameException;
abstract String normalizeAbsoluteName(String name) throws
MalformedTemplateNameException;
}
My idea was that if we allow users to provide a custom implementation,
then if the standard rules don't fit your custom TemplateResolver, you
just create a custom TemplateNameFormat too. But now that I think
about it more, pushing the TemplateNameFormat functionality on the
TemplateResolver implementation does indeed look like a better
approach, because then it can't happen that a configuration
accidentally contains a TemplateResolver with a TemplateNameFormat
that doesn't work well with it. But then the above two methods should
be part of the TemplateResolver interface (because, for example, when
you #import something, FM has to find out if the same FTL was already
imported in the current Environment, so it needs to normalize the
#import argument without loading anything). WDYT?
> 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.
That's even a problem with the TemplateLoader interface proposed to
FM3. Like in the recent database template loader thread, the author
wanted to use a separate column to indicate the locale of the template
(and the same could happen with custom lookup conditions too), so you
don't want to encode that information into the template name in the
case of that particular TemplateLoader. It's something we may try to
address in a second iteration of the FM3 TemplateLoader interface.
> 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.
BTW, I still want to see if in FM3 the standard TemplateResolver (the
one that's basically FM2's TemplateCache, relies on TemplateLoader and
TemplateLookupStrategy and TemplateNameFormat) could cover more use
cases without becoming overly intricate. Also, even if you decide to
use a custom TemplateResolver, perhaps you still want to call some of
the stock TemplateLoader-s from it (while you replace the caching
logic, etc., or load from non-TemplateLoader sources too in case of
more sophisticated storages). I suspect you have experience with these
things, so it would be good if you can look at the FM3 TemplateLoader
thread.
> -David
--
Thanks,
Daniel Dekany
