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
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:
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,
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
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
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
Thanks Blake, that works for me.
On Wed, Jan 20, 2010 at 5:41 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:
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
