Re: Template Loaders and Acquisition Mechanism

Thursday, October 15, 2009, 8:01:45 PM, Daniel Dekany wrote:

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

Nah, not good. We have to truly understand some of the "variation
tags", because we set settings in templates according them and like.
Also we can't have true tags, because we only store the value of tags
in the file names, which leads to ambiguities and hence some issues to
address. So, I think we need something like this:

public final class TemplateVariation {

   /**
    * Always use some special character before the values, but not @!
    * If you don't the setter will throw exception.
    */
   @BeanProperty String[] mostImportantPostfixes;

   /**
    * Will use @ prefix in the file names, but you must start the
    * items with letter or digit when setting this.
    * E.g., String[]{"paper"}, String[]{"paper", "coated"}, etc.,
    * will produce _@paper and _@paper_@coated, etc., in the
    * file name.
    */
   @BeanProperty String[] targetMedia;

   /**
    * The only variation marker that uses no prefix in the file
    * name.
    */
   @BeanProperty Locale locale;

   /**
    * Always use some special character before the values, but not @!
    * If you don't the setter will throw exception.
    */
   @BeanProperty String[] lessImportantPostfixes;

}

So we have getTemplate(String name, TemplateVariation tv), which will
somewhere do theTemplate.setLocale(tv.getLocale()) and
theTemplate.setTargetMedia(tv.getTargetMedia()) when we got the
Template. Also it should set @BeanProperty
theTemplate.templateVariations, so the custom variation markers will
be available, just like locale and targetMeida are.

As of finding the best matching template, it should just construct
List<String> finalPostfixList, which is the result of appending
mostImportantPostfixes + targetMediaPrefixes + localePrefixes +
tv.lessImportantPostfixes.

So you end up with something like

  String[]{
          "!foo", "!bar", "!baaz",
          "$mammal", "$wombat",
          "@mobile",
          "en", "US", "Mac",
          "~violet"}

Easy. Also not the most generic, but then FreeMarker can't be that
anyway without adding significant extra complexity to the public API.
(OK, perhaps it could be, if we add a totally new storage API and then
implement the current "rigid" one on top of that for BC... different
topic.) Is this good enough for a FreeMarker, or should we complicate
it a bit more?

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