myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeanne Waldman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (TRINIDAD-1691) Skinning framework support for skin versioning
Date Wed, 20 Jan 2010 23:52:54 GMT

    [ https://issues.apache.org/jira/browse/TRINIDAD-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803065#action_12803065
] 

Jeanne Waldman commented on TRINIDAD-1691:
------------------------------------------

Why isn't putting the version into the skin-family name good enough? <skin-family>purple1.1.12.4</skin-family>.
It's not quite the same as versioning, since we wouldn't change the version number every time
we release.

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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message