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
>>>