You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Pavitra Subramaniam <pa...@oracle.com> on 2010/11/01 19:00:42 UTC

Re: [TRINIDAD] public API review - SkinVersion

For some reason my first email to dev@myfaces.apache.org bounced. 
Resending...

On 11/1/2010 10:55 AM, Pavitra Subramaniam wrote:
> Hello Jeanne,
>
> On 11/1/2010 9:07 AM, Jeanne Waldman wrote:
>> yes, that sounds like a good idea.
>>
>> Blake Sullivan wrote, On 10/29/2010 2:35 PM PT:
>>> I'm wondering if we're making the subclasser implement equals() in 
>>> SkinVersion if we should make hashCode() abstract as well so that 
>>> they remember to provide their own implementation there as well.
>>>
>>> -- Blake
>>>
>>> On 10/29/10 2:30 PM, Jeanne Waldman wrote:
>>>> Hi,
>>>>
>>>> I've been asked to implement something called skin versioning into 
>>>> the skinning framework. This is useful when you (the skinning 
>>>> developer) want to update your skin, and you want to version it, so 
>>>> that an end user can decide if he wants to uptake your new version 
>>>> without changing the skin-family name, and keeping the skin-family 
>>>> name version-free.
>>>>
>>>> In trinidad-config.xml, the application developer chooses the 
>>>> skin-family to use. We will now have a skin-version field as well:
>>>> <skin-family>purple</skin-family>
>>>> *<skin-version>v2</skin-version>*
>>>>
>>>> The syntax *<skin-version>default</skin-version>* can be supported 
>>>> as well to return the purple skin whose version is marked to be the 
>>>> default skin in that skin-family.
>>>> We could also add a *<skin-version>latest</skin-version>* so an end 
>>>> user can say, "I always want the latest purple skin", and they'll 
>>>> never have to change their trinidad-config.xml every time a new 
>>>> purple skin version comes out.
> How do you pick the 'latest' skin? Is there a <latest> element under 
> <skin>... <version>, just like <default>?
>>>>
>>>> In trinidad-skins.xml (the skin developer) could add versioning to 
>>>> the skins like this. The name of the version can be any String the 
>>>> skin developer wants. Here we've chosen "v1" and "v2".
>>>>
>>>> <skin>
>>>> <id>purple-v1.desktop</id>
>>>> <family>purple</family>
>>>> * <version>
>>>> <name>v1</name>
>>>> <default>true</default>
>>>> </version>*
>>>>   ...
>>>> </skin>
>>>> <skin>
>>>> <id>purple-v2.desktop</id>
>>>> <family>purple</family>
>>>> * <version>
>>>> <name>v2</name>
>>>> </version>*
>>>>   ...
>>>> </skin>
>
> - Why not have one <skin> element that supports multiple versions? It 
> seems like when the 'id' could automatically include the version that 
> is requested/used at runtime. Something like
>
> <skin>
> <id>purple-desktop</id>
>   ...
> <versions>
> <version>
> <name>v1</name>
> <default>true</default>
> </version>
> <version>
> <name>v2</name>
> <latest>true</latest> ----> // is there a latest element?
> </version>
> </versions>
> </skin>
>
> I think that repeating the skin element may be error prone since the 
> user would have to specify an <id> for each that is unique and that 
> includes the version name. wdyt?
>
> Thanks
> Pavitra
>
>>>>
>>>> The SkinVersion will be a class and not simply a String so we can 
>>>> add 'default' and maybe 'latest' flags to it.
>>>> A Skin object will have a SkinVersion. A Skin object already has an 
>>>> id, a family, a styleSheetName, etc.
>>>>
>>>> package org.apache.myfaces.trinidad.skin;
>>>>
>>>> /**
>>>>  * You can version skins. The skin version works tightly with the 
>>>> skin family.
>>>>  * This allows someone to create versions of their skin, like 
>>>> purple, purple-v2,
>>>>  * purple-v3. Then the user can say which skin version they want, like:
>>>>  * <skin-family>purple</skin-family><skin-version>v3</skin-version> 
>>>> when they
>>>>  * pick a skin in trinidad-config.xml.
>>>>  * When creating a skin, you give it a version if you care about 
>>>> versioning.
>>>>  * When extending this class, you must override equals.
>>>>  */
>>>> abstract public class SkinVersion
>>>> {
>>>>
>>>>   // when extending this class, you must override equals
>>>>   abstract public boolean equals(Object o);
>>>>
>>>>   abstract public boolean isDefault();
>>>>
>>>>   abstract public String getName();
>>>>
>>>> }
>>>>
>>>> Let me know what you think.
>>>>
>>>> Thanks!
>>>> Jeanne
>>>