that would be extremely tedious if you want to override it for all
components in your application :)

-igor

On Tue, Mar 3, 2009 at 8:54 PM, Anton Veretennikov
<[email protected]> wrote:
> per each component?
>
> On Wed, Mar 4, 2009 at 11:52 AM, Igor Vaynberg <[email protected]> 
> wrote:
>> we cannot make this overridable because it breaks encapsulation.
>>
>> imagine you write a table component that includes styles and
>> variations. i then want to use it in my app where i have overwritten
>> this syntax, now my app wont pick up your styles and variations.
>>
>> so we need to come up with something simple that everyone can agree on.
>>
>> -igor
>>
>> On Tue, Mar 3, 2009 at 8:48 PM, Anton Veretennikov
>> <[email protected]> wrote:
>>> String getFileNameTemplate() {
>>>  return 
>>> "fileName([styleName][_variationName])[language[_territory][.codese...@modifier]]";
>>> }
>>>
>>>
>>> On Wed, Mar 4, 2009 at 11:47 AM, Igor Vaynberg <[email protected]> 
>>> wrote:
>>>> but there is a special rule about the _ prefix to indicate a
>>>> variation, where as a simple empty bracket is easy - its always
>>>> consistent [style][variation][locale]. just my two cents.
>>>>
>>>> personally i never had to use variations myself, but there were
>>>> threads in the past about them, so i guess someone somewhere is using
>>>> them.
>>>>
>>>> -igor
>>>>
>>>> On Tue, Mar 3, 2009 at 8:44 PM, jWeekend <[email protected]> 
>>>> wrote:
>>>>>
>>>>> Igor,
>>>>>
>>>>> I'd say your
>>>>>
>>>>> "HomePage[style_variation]_US_en.html that way a style only version can be
>>>>> HomePage[style]_US_en.html and variation only would be
>>>>> HomePage[_variation]_US_en.html we can then forbid the use of _ in style 
>>>>> and
>>>>> variation names. "
>>>>>
>>>>> is the best option (so far). There are no special rules or empty brakets
>>>>> unless you choose to use Wicket specific features (style and variation).
>>>>> And, it somehow looks less ugly than some of the other suggestions,
>>>>> especially mine!
>>>>>
>>>>> Thanks for the example use-case; I expect someone, somewhere out there is
>>>>> making good use of "variations".
>>>>>
>>>>> Regards - Cemal
>>>>> http://jWeekend.com jWeekend
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> igor.vaynberg wrote:
>>>>>>
>>>>>> i dont like the fact that there is now a -, (, ), and _ in the name
>>>>>>
>>>>>> i can live with something like HomePage()(variation)_US_en.html vs
>>>>>>
>>>>>> HomePage()(variation)(US_en)
>>>>>>
>>>>>> maybe even simpler would be do
>>>>>>
>>>>>> HomePage[style_variation]_US_en.html
>>>>>>
>>>>>> that way a style only version can be HomePage[style]_US_en.html
>>>>>>
>>>>>> and variation only would be HomePage[_variation]_US_en.html
>>>>>>
>>>>>> we can then forbid the use of _ in style and variation names.
>>>>>>
>>>>>> its a little more complex but avoids an empty [] or () to indicate
>>>>>> variation only markup.
>>>>>>
>>>>>> I still think that HomePage[][variation][US_en].html does look cleaner
>>>>>> and simpler then
>>>>>>
>>>>>> HomePage[][variation]_US_en.html or HomePage[_variation]_US_en.html
>>>>>>
>>>>>> because in HomePage[][variation][US_en] you only have to know [] as
>>>>>> separators.
>>>>>>
>>>>>>
>>>>>> the usecases for variations vary. suppose your application is divided
>>>>>> in two frames and the user can select the color scheme for both.
>>>>>> having a single value for style wont work here, it has to be per
>>>>>> component.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Tue, Mar 3, 2009 at 7:18 PM, jWeekend <[email protected]>
>>>>>> wrote:
>>>>>>>
>>>>>>> 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]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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-tp22302526p22323611.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]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>>
>
> ---------------------------------------------------------------------
> 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