Thanks Blake, that works for me. On Wed, Jan 20, 2010 at 5:41 PM, Blake Sullivan <blake.sulli...@oracle.com>wrote:
> Matt, > > I don't think that an explicit versioning scheme should be necessary. In > your example, we have the base skin A, a version with big enough changes > that the designer feels that it should have an new name, B, that extends A > and an application extension of A, C. The issue is that the user of the > application can't choose B immediately because the C extends the original > skin A and not the new skin B. However, it would seem that the same logic > that drove the original skin designer to create a new skin B rather than > simply modifying skin A should apply in this case. If the changes were big > enough for us to need a new skin, doesn't this imply that other extenders of > the original skin should need to opt in as well? The changes that skin C > made to change A may not be compatible with those made by skin B, so the > application needs to verify this before making a new skin C' that extends B > instead of A. The grossness here would be if the application wanted to make > both skins C and C' available and thus wanted to share overrides between the > two. However, the addition of inclusion support would presumably make any > refactoring for sharing easy to take advantge of. > > -- Blake Sullivan > > > Matt Cooper said the following On 1/20/2010 3:35 PM PT: > > If the application developer is injecting a skin addition into skin "A" and > if skin "B" (aka version 2) extends from skin "B" then this is not an issue. > > However, if the application developer has created their own skin that > extends skin "A" then the end user cannot choose skin "B" (aka version 2) > because the application developer is not also providing a separate skin that > extends skin "B". > > One of the main reasons why applications will choose extending a skin over > injecting a skin addition is that a skin addition does not guarantee any > order in which the definitions will be injected into the skin so if there > are competing definitions then it will be a matter of luck whether the > application developer's definitions will win. However, by extending a skin, > the application developer's definitions are guaranteed to override the > existing selector of the base skins (provided the selectors are identical). > > In an ideal world, we wouldn't have a skin "B" (version 2) at all and the > reasoning that the UI designer came up with the new design would be > justification enough for why skin "A" needs to change. If there is no > justification then we should push back on the UI designer or just live with > there being a separate unrelated skin. Perhaps this isn't a very common use > case to warrant a versioning system? > > Thanks, > Matt > > On Wed, Jan 20, 2010 at 4:15 PM, Blake Sullivan<blake.sulli...@oracle.com> > <blake.sulli...@oracle.com>wrote: > > > > Do they? I always get confused by which is which between skin additions > and skin extensions. Anyway, why wouldn't skin A' that extends Skin A pick > up all of the extensions and additions to A? Or, is the case you are > worried about that the customer has their own skin B that extends skin A but > wants to pick up the changes available in A'. However, in that case, isn't > the change still essentially one line? Instead of changing trinidad-config > to point to A' (since it already points to B), the skinner changes skin B to > extend A'? > > The reason I'm pushing back on this is that the skin files are confusing > enough without adding skin versioning into the mix. > > -- Blake Sullivan > > Matt Cooper said the following On 1/20/2010 3:09 PM PT: > > 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<blake.sulli...@oracle.com> > <blake.sulli...@oracle.com> <blake.sulli...@oracle.com> > <blake.sulli...@oracle.com>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. > > > > > > > > > > >
