extend common base component?

On Wed, Mar 4, 2009 at 11:56 AM, Igor Vaynberg <[email protected]> wrote:
> 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]
>
>

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

Reply via email to