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]
