Re: Template Loaders and Acquisition Mechanism

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


------------------------------------------------------------------------------
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