Multi-templating System (JAVASERVERFACES_SPEC_PUBLIC-971)

[JAVASERVERFACES_SPEC_PUBLIC-316] Skinning Created: 04/Oct/07  Updated: 01/Jul/13  Resolved: 01/Jul/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Sub-task Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 12
Labels: None
Remaining Estimate: 2 weeks, 1 day
Time Spent: Not Specified
Original Estimate: 2 weeks, 1 day

Operating System: All
Platform: All

Issue Links:
blocks JAVASERVERFACES_SPEC_PUBLIC-246 Improve Component Library Interop (wa... Closed
Issuezilla Id: 316
Status Whiteboard:

EGTop5 effort_hard cat2 frame size_large importance_medium


Provide support for skinning:

  • Easy customizable theme/skin API. Skinability Framework, that
    includes Skin parameters API, dynamically generated CSS and Images
    using Skin parameters (related to Resource Framework), easy use of
    Skin parameters from pages and Components.

Comment by Ed Burns [ 04/Oct/07 ]

Add blocks 245

Comment by Ed Burns [ 20/Aug/08 ]
      • Issue 351 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 09/Sep/08 ]

Push to 2.1

Comment by Ed Burns [ 12/Sep/08 ]


Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 21/Oct/08 ]

The whole "Umbrella issue" thing didn't work out as planned. Changing summary back to be specific.

Comment by Ed Burns [ 24/Sep/09 ]

Didn't get to this.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. isn't
specific enough.

Comment by Ed Burns [ 04/Mar/10 ]


Comment by Ed Burns [ 22/Mar/10 ]

This might make sense to be in JSCL

Comment by Ed Burns [ 22/Mar/10 ]


Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]


Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]


Comment by Ed Burns [ 31/Jan/11 ]

This should be handled in a JSR that is dedicated to producing a standard component library for JSF

Comment by lamine_ba [ 14/Apr/11 ]

I'm not a big fan of components libraries skinning. They are just making the job of a web designer more harder. After having defined the structure of his web interface, a web designer from a clean state will think about how to stylize the HMTL elements (a, h1, div, and so forth...) and not how to stylize your components. What is the finality of an UIComponent? isn't it to render HTML content? Thus providing a default and general css could be a good answer to this problem and my multi-templating feature another one because each template will come with its own css files to make an application change its look and feel. But are these solutions enough in the perspective to have any single UIComponent available in the JSF ecosystem to be customizable with css? wow, how many style classes should we remember in this case? too much for my little head thus I'm only with you if you find conventions at first

Comment by kito75 [ 19/Apr/11 ]

I think this should really be part of the core JSF spec, unless we're going to have a components spec anytime soon. We really need to standardize the work done by the component vendors so life is easier for developers who use more than one component suite (and component vendors don't have to reinvent the wheel).

Comment by lamine_ba [ 24/Apr/11 ]

Multi-templating = Theming + Skinning

Seam Themes (

How a web designer can create different themes for a JSF application?
How a web designer can create different skins for a JSF application?
How can we share the themes?
How can we share the skins?
How can we package and unify the two concepts into one?

Wouldn't be nice if you could download and use this kind of templates ( )

Want to have a system like this one? (

Related issues:

Multi-templating :

Comment by rdelaplante [ 19/Jan/12 ]

Cross posting a comment from the JAVASERVERFACES_SPEC_PUBLIC-971 ticket because it is relevant:

I have implemented a similar concept in JSF as well. In my experience you need a hierarchy of message resource bundles as well. You have a global system bundle for the majority of messages, and a template/brand/theme specific resource bundle that can override any of the global system messages, as well as add additional messages needed by the template/brand/theme (for their header, footer, etc.) You also need to take into account images that have text on them and need to be localized.

Also, we have created a .xhtml facelet file for every screen of our application in each template/brand/theme directory. It's not just the header/footer that changes... the way they want to lay out panels looks different, their placement of buttons, etc. We need to make our application look exactly like the customer's existing website so their customers don't realize they have gone to another site for our particular workflow. Every customer is totally different.

One more comment... every resource used by our template/brand/theme is listed in a configuration file so that when a web user requests it, we can make sure they are allowed to read that file and don't try to hack the system by doing things such as ../../../../. When I say resource, I'm talking about images, JavaScript files, CSS files, etc.

Comment by Ed Burns [ 01/Jul/13 ]

Resource Library Contracts is our current offering for what passes as skinning. If this feature needs to be re-addressed, another issue must be opened.

Generated at Wed Dec 02 05:07:04 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.