Re: Template Loaders and Acquisition Mechanism

I think I follow your line of thought... Should these keys configured for the map passed to getTemplate() be from a predefined set of keys (so user can only configure keys offered by Freemarker, like locale, @target_media), or custom keys would be allowed?

Also, what naming convention do you think it should be used for template names? The same like for locales, with _ separator?

When you reach a consensus about the solution that's worth investigating, you can let me know, and I could work on a 'test' implementation to see how it works.

Regards,
Darko

--- On Thu, 10/15/09, Daniel Dekany <[email protected]> wrote:

From: Daniel Dekany <[email protected]>
Subject: Re: [FreeMarker-user] Template Loaders and Acquisition Mechanism
To: "Attila Szegedi" <[email protected]>
Cc: "FreeMarker-user" <[email protected]>, "Darko Radosevic" <[email protected]>
Date: Thursday, October 15, 2009, 8:01 PM

Thursday, October 15, 2009, 2:46:16 PM, Attila Szegedi wrote:

> Okay, let me chime in a bit with my view of this... Locale used to be
> a single customization we allowed, and one that follows naturally from
> the majority natural use of text generating systems - namely,  
> generating text for human use; localization is a requirement for any  
> modern text-processing system.
>
> Now, as soon as second classification arises (media type), I'm no  
> longer so sure that we want to hardwire it too. Or hardwire locale  
> anymore, except for backwards compatibility. Because, this indeed  
> starts to sound as if it were becoming a general concept, isn't it?  
> Together with the order of precedence, and eventual hierarchy of  
> values (think of it - Locale values form a three-level hierarchy, and
> we actually have code recognize this and act accordingly). So, I'm  
> thinking we should shoot for some general extensibility here instead  
> of a quick patch.

Well, FM doesn't have a very flexible storage mechanism anyway (as it
makes many assumptions (for exaple that's why it can't implement
Zope-like acquisition)), but OK, why not do it a bit more flexible. I
think it just should be a Map passed to getTemplate, plus a
TemplateCache-level (Configuration-only setting for the user) list of
keys, that thus specifies the precedences. Just a quick thought
anyway.

> Even if this proved too hard, and we remained with a fixed set of  
> customizations, I'd rather not add another argument to the  
> findTemplateSource and any other methods that take a (String, Locale)
> tuple. For sake of future extensibility, we should have a class instead:
>
> public class TemplateSpecification {
>      private String name;
>      private Locale locale;
>      private String targetMedia;
> }
>
> and have all methods that took a (String, Locale) pair now take an  
> instance of TemplateSpecification (keeping the existing ones, but  
> deprecating them). That way, we can compatibly extend it in future  
> with multiple fields and not have to change the signature of the  
> methods - any fields with null value mean "not specified".
>
> But I'd like to think a bit first about the direction of having a  
> general mechanism - something where you can pass a Map (instead of  
> TemplateSpecification), or maybe an URI, and have the components  
> resolved as necessary.
>
> Attila.
>
> On 2009.10.15., at 12:33, Daniel Dekany wrote:
>
>> Wednesday, October 14, 2009, 6:44:06 PM, Darko Radosevic wrote:
>>
>>> Hi,
>>>
>>> thanks for the helpful response.
>>>
>>> I found some workarounds using the optional 3rd part of the locale
>>> string, but they have some limitations (must supply the mobile
>>> templates for each possible locale, or choose one locale and
>>> therefore make localization unusable).
>>>
>>> Now, about a possible patch. I'm interested in submitting the
>>> patch, but I have some questions. I know whether I need 'mobile' or
>>> 'standard' template at the time when I'm calling
>>> Configuration.getTemplate() method. Will this new 'target media'
>>> setting be an additional parameter in the getTemplate() method, or
>>> it will be new setting in Configuration? Or the setting in
>>> Configuration will be used to enable/disable this new target media
>>> lookup?
>>
>> The way these kind of things work is that (almost) all settings
>> defined on three levels, see:
>> http://freemarker.org/docs/pgui_config_settings.html
>>
>> So, the new target_media setting needs to be added on all 3 levels of
>> FreeMarker.
>>
>>> I guess we need to create an additional method similar to
>>>
>>> private Object findTemplateSource(String name, Locale locale)
>>>
>>> in TemplateCache, or modify this method.
>>
>> Yes, just add a new parameter, String targetMedium, etc. Also
>> TemplateCache.getTemplate will need an overloaded version (because the
>> original is public, it can't be changed), and
>> Configuration.getTemplate too... these are trivial to do too. The
>> template language may will need a new special-variable, .media, akin
>> of .locale, so it's again mostly just copy-paste. What else? I think
>> technically that's it. I will add the relevant parts to the
>> documentation.
>>
>>> I'm not familiar with the Freemarker development process, so I'd
>>> like to know what are the chances for this patch being
>>> accepted/rejected as a part of official Freemarker release?
>>> Do you know some approximate timeframe for this? I'm asking because
>>> this will have an impact on the project I'm working on.
>>
>> Inherently we are not bureaucratic and quite flexible and fast and
>> whatever, but let's see what are the extra hops:
>>
>> - Nowadays you can't contribute without signing a CLA. That's a paper
>>  I send to you in e-mail (now), you sign it by hand, and post it to
>>  us in snail mail. Yeah, it has to reach a Hungarian address. Sorry
>>  about all that, but since big corps started to use FM... you know.
>>  After we received the CLA, you get write access to the SVN repo,
>>  fire up Eclipse (if you like), and just work and commit... we
>>  automatically receive e-mail reports about the changes, so generally
>>  you are not expected to ask before committing, as far as you are
>>  working on the feature we know about.
>>
>> - Changes should be forward-ported to the 2.4 branch... Easy, but
>>  still some boring extra work.
>>
>> - I didn't yet received any responses from the other two "heads",
>>  regarding if they agree that this feature has place in FreeMarker.
>>  If they don't respond soon, well... I think I will just assume it's
>>  accepted.
>>
>> - You don't have to wait for 2.3.16, as far using the nightly build is
>>  OK for you. At least someone tests it... ;) But 2.3.16 should be
>>  released in weeks. Like, even on next week weekend or something.
>>
>>> If you have some guidelines or suggestions for starting the work on  
>>> this patch, please let me know.
>>
>> I think above it was covered. But ask if something is unclear.
>>
>>> Thanks,
>>> Darko
>>>
>>> --- On Thu, 10/8/09, Daniel Dekany <[email protected]> wrote:
>>>
>>> From: Daniel Dekany <[email protected]>
>>> Subject: Re: [FreeMarker-user] Template Loaders and Acquisition  
>>> Mechanism
>>> To: "Darko Radosevic" <[email protected]>
>>> Cc: [email protected]
>>> Date: Thursday, October 8, 2009, 5:28 PM
>>>
>>> Thursday, October 8, 2009, 3:25:15 PM, Darko Radosevic wrote:
>>>
>>>> Hi,
>>>>
>>>> we have templates placed in folder hierarchy (default/client/site)
>>>> and we're using default FileTemplateLoader and acquisition mechanism
>>>> to load templates. But now we want to introduce a brand new type of
>>>> templates - templates for mobile site. The mobile templates should
>>>> follow this same default/client/site hierarchy but they should take
>>>> precedence over regular templates when the request is coming from a
>>>> mobile device. We could diferrentiate mobile templates by placing in
>>>> separate folder or by "m_" name prefix, we haven't decided yet. So,
>>>> loading order on a mobile site should be:
>>>>
>>>> 1. mobile site template 2.mobile client 3 mobile default 4.standard
>>>> site 5 standard client 6.standard default
>>>>
>>>> This looks tricky to solve, I've first tried to utilize
>>>> MultiTemplateLoader and some custom TemplateLoaders, but I would  
>>>> get only this loading order:
>>>>
>>>> 1. mobile site 2.standard site 3.mobile client 4. standard client
>>>> 5. mobile default 6.standard default.
>>>>
>>>> The only working solution I've found so far is to use two
>>>> Configurations,
>>>
>>> Don't do that, it's not how Configurations meant to be used.  
>>> Templates
>>> returned by one of the Configuration-s will search their dependences
>>> using that Configuration. This also means that you will end up some
>>> templates cached twice... and who knows what else I didn't realized
>>> right now.
>>>
>>>> each having different base folder. In case 'mobile'
>>>> Configuration throws FileNotFoundException, try to use 'standard'
>>>> Configuration. The problem with this solution is that we'll need
>>>> copy all templates from the 'standard' folder to the 'mobile'  
>>>> folder and then maintain duplicates.
>>>>
>>>> The only other possible solution I see is to rewrite TemplateCache
>>>> to maybe somehow  move acquisition mechanism inside template loader,
>>>> but this looks way too low-level...
>>>
>>> You couldn't even do that there in a way so it will work correctly.
>>>
>>>> Do you know of any cases where TemplateCache is overwritten with
>>>> some diferrent implementation, or do you know of some Freemarker
>>>> features that could be useful for me?
>>>
>>> Maybe you can do the trick with the localization feature... like if
>>> being mobile optimized would be a locale variation (you know, the
>>> optional 3rd part of the locale string). Localization quite much does
>>> what you need, in that it first tries to find the most locale- 
>>> specific
>>> template variation with acquisition, and only when that fails tries  
>>> it
>>> to find a less-specific one.
>>>
>>> Now if it doesn't work out well with localization, you can still
>>> submit a patch. But then let's see what should be achieved... you  
>>> want
>>> to specify the target *media* here. It's very much like localization
>>> right now, so it should look similarly: [email protected],
>>> mytemplate_@mobile_en.ftl, mytemplate_@mobile_en_US.ftl, etc. It's @
>>> because that's also what CSS uses for media selection, and it's also
>>> suggestive: the page "at a mobile", "at a printer". I think the media
>>> should have higher priority than locale, and that's also what you
>>> wanted here. If a different need arises, we can still add a
>>> media_priority setting. Yeah, and target_media itself is a new
>>> setting. Pretty much like locale.
>>>
>>> Objections?
>>>
>>> Of course, you may ask for some guidance if you want to do the patch.
>>>
>>>> Thanks,
>>>> Darko
>>>
>>
>> -- 
>> Best regards,
>> Daniel Dekany

-- 
Best regards,
 Daniel Dekany

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

_______________________________________________
FreeMarker-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-user