Igor,

In Java, variant is the least significant component(s) of a locale:
lang_COUNTRY_variant  . 

Wicket adds style and variation (right?) so maybe only these components of
the filename should have a special marker. That way, some level of
consistentcy is maintained and the Wicket specific style & variation are
clearly identifiable.
So, for example, HomePage-aStyle(aVariation)_th_TH_TH.html   - in this
example you'd need to double check that dash and the parenthesis can be used
in file names on all relevant filesystems (you could even make the markers
configurable I suppose in Application#init and/or using system properties
...). Of course it's not pretty; at the end of the day, your stuck with
character strings so you can't stop people confusing themselves (and maybe
Wicket too) with funky file names using these "special" characters.

The javadoc says: Whereas Styles are Session (user) specific, variations are
component specific. E.g. if the Style is "ocean" and the Variation is
"NorthSea", than the resources are given the names suffixed with
"_ocean_NorthSea".

Is there a standard use-case where the solution involves using variation
(that's in keeping with the original intent)?

Regards - Cemal
http://jWeekend.com jWeekend 


igor.vaynberg wrote:
> 
> yeah, not to mention it might get quiet ugly
> 
> mypanel_style.html
> mypanel_style__variant.html
> mypanel_style__variant___locale.html
> 
> mypanel__variant.html
> 
> mypanel___locale.html
> 
> markup(locale)(style)(variant) might work and is simpler
> 
> mypanel(en_us).html
> 
> mypanel(en_us)()(variant).html
> 
> but sure looks ugly... :)
> 
> not sure which one is better
> 
> -igor
> 
> 
> On Mon, Mar 2, 2009 at 11:30 PM, Ned Collyer <[email protected]>
> wrote:
>>
>> Yep :).
>>
>> I at least 1 thought on this matter.
>>
>> Currently, I have a "webapp" module - which will have my components in
>> it,
>> and my components variants.
>>
>> I have pushed all i18n into properties files - which is working thus far.
>>
>> I allow the clients to customise their HTML from another folder - ie,
>> someplace on the filesystem outside of the war.
>>
>> The lookup for html files for me .. should be
>>
>> custom dir - myPanel_myVariant_myStyle.html
>> webapp.war - myPanel_myVariant_myStyle.html
>> custom dir - myPanel_myVariant.html
>> webapp.war - myPanel_myVariant.html
>> custom dir - myPanel_myStyle.html
>> webapp.war - myPanel_myStyle.html
>> custom dir - myPanel.html
>> webapp.war - myPanel.html
>>
>> I have a similar thing in place for properties files - and the result is
>> actually a merge of the properties between filesystem and classpath.
>>
>> So many ways to skin a cat.  If only we could skin this cat with locale,
>> style AND variant - each optional.
>>
>> More static count of delimiters? Folder structure? Different delimiters?
>> Different data in filename? Contents of file?
>>
>> The balancing act is keeping it simple - which its currently nailed, but
>> not
>> quite as useful as it could be!!!
>>
>>
>> igor.vaynberg wrote:
>>>
>>> the problem is, if you have MyPanel_foo.html, is foo the style, the
>>> variation, or the locale?
>>>
>>> perhaps we can identify the parts differently...needs some thinking.
>>>
>>> -igor
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Question-re%3A-style-and-variation-tp22302526p22303708.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Question-re%3A-style-and-variation-tp22302526p22322875.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to