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