Hi Blake, Aside from the opt-in setting for end users choosing which skin to display, application developers would also be impacted. Application developers would need to extend all skins instead of just extending 1 skin whose version number could be arbitrarily changed by the end user.
Thanks, Matt On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivan <[email protected]>wrote: > Matt, > > Why wouldn't it be sufficient for the new skin the extend the old? What > problems does this add other than forcing customers to modify their > trinidad-config to use the new skin name in order to opt in? > > -- Blake Sullivan > > Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT: > > Skinning framework support for skin versioning >> ---------------------------------------------- >> >> Key: TRINIDAD-1691 >> URL: https://issues.apache.org/jira/browse/TRINIDAD-1691 >> Project: MyFaces Trinidad >> Issue Type: New Feature >> Components: Skinning >> Reporter: Matt Cooper >> >> >> UI designers periodically create new UI designs for various components >> with the goal of these designs being applied to a specific skin. Although >> the visual design might be completely new for a given component, it is >> really meant to be available in context of other existing component designs >> of the same existing skin. >> >> UI changes like this are sometimes considered to jarring for some >> customers and they would rather stick with the original designs. This means >> that skins are eternally frozen after their first release so any new changes >> would need to be made in a new skin even though that new skin might be 75% >> identical to the original skin. >> >> There is also a negative impact on customers that generate their own skin >> definitions when we introduce a new skin name. Every skin (or skin >> addition) that they have created won't be able to uptake the new designs >> unless they physically go in and change all references from the old skin >> name to whatever the new skin's name is. To remedy this while enabling the >> "frozen" state of the original designs, the skinning framework must support >> a concept of versioning. Since the nature of software means that code lines >> branch into a vast tree structure, the version numbers of the skinning >> framework must fulfill this need. A simple "x.y" will not be sufficient, we >> will require "x.y.z.a.b.c.d.e.f.g" and so on where each "." represents >> another code branch off of the previous code branch, e.g. there will likely >> be a version that looks like "1.1.12.4". >> >> Customers will then need a configuration option where they can specify >> which version of the skin they want to use. (Presumably near the same >> location where they specify which skin name they want to use.) >> >> Business needs: >> Some customers need new UI designs applied to existing skins but other >> customers need the skin to remain unchanged. Versioning will allow >> customers to optionally buy-into the new UI designs while other customers >> can happily live with the past designs. >> >> >> > >
