Only if someone needs to implement other file name policy and at the same time don't want to copy & paste. My mite only: this is encapsulating AND flexible but...difficult to code.
On Wed, Mar 4, 2009 at 12:01 PM, Igor Vaynberg <[email protected]> wrote: > for every panel, textfield, label, tabbedpanel, etc, etc, etc? > > -igor > > On Tue, Mar 3, 2009 at 8:58 PM, Anton Veretennikov > <[email protected]> wrote: >> 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] >> >> > > --------------------------------------------------------------------- > 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]
