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]

Reply via email to