Re: Template Loaders and Acquisition Mechanism

Guys, we have to reach some consensus on this, or it won't make into
2.3.16. That thing really should be released, like, this weekend (if I
will find time for it then.) (However, I'm still waiting for something
regarding the detection of buggy Bean sequences. But if there won't be
any, I might as well add an isBuggySequence method to that
TempalteModel.)

Anyway, I don't think it's a big problem if it doesn't make it into
2.3.16, as it can then go into the nightly, and surely Darko Radosevic
can use that until 2.3.17 is out. Can you?


As of my proposal, it needs some refinement. To recap, the base idea
is that we simply construct a list of postfixes, and try finding the
most specific file variation be repeatedly dropping the last prefix.

As far as I see, the problem of the proposal is that it can't insert
custom postfixes between the targetMedia and the locale. That could be
solved by adding yet another String[] JavaBean property, but then what
if we later add yet another predefined variation property... well, I
guess we wont, but some may disagree.

Also the proposal didn't address if what's if someone wants locale
have higher priority than targetMedia... well, a Configuration-level
setting could be added later for that, if it turns out to be useful.

Last not least, obviously the most flexible solution would be if
instead of a TemplateVariation the user can specify some kind of
FileNamePrefixGenerator, which would generate the full, composite
prefixes like "_!admin_@paper_en_US" directly, starting with the most
desired one, going towards the less specific ones (which is maybe
"_!member_@paper_en_US"; you noticed the custom logic there). But then
querying the "tags" had to be solved too... etc. So we might as well
go for the less flexible solution instead of hunting down an imaginary
problem with abstraction bloat. (No, the problem of specifying custom
ways of finding matching templates is not an imaginary problem at all,
but like I said, solving that would require much deeper API changes
than fiddling with these prefixes.)


Friday, October 16, 2009, 1:48:21 PM, Daniel Dekany wrote:

> 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