jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] [PROBLEM_ViewIdentification] DISCUSSION ResourceHandler and Multitemplating (FaceletCache interface does not handle "relativeLocations" logic from DefaultFaceletFactory)

From: Edward Burns <edward.burns_at_oracle.com>
Date: Thu, 12 Jul 2012 07:45:13 -0700

>>>>> On Sun, 8 Jul 2012 16:50:55 +0200, Frank Caputo <frank_at_frankcaputo.de> said:

FC> Hi Leonardo,
FC> having localized composite components is a great idea and goes with my skinning idea. But I still can't see, why we should limit skinning to templates. We should make a resource identifier contain a skinPrefix, to have a nice fallback scenario as with the locale:

FC> [skinPrefix]/[localePrefix/][libraryName/][libraryVersion/]resourceName[/resourceVersion]

FC> This way we don't need any configuration for skinning just a skin
FC> detecting method in the FacesContext as I mentioned earlier.

Maybe so, but under no circumstances should the skinPrefix be sent down
to the client in a response or up from the client in a request. I see
that sort of information as similar to libraryVersion or
resourceVersion. That sort of information resides on the server as part
of the application state. This is a fundamental design choice of
resource handling in JSF 2.0.

For example, in the case of versions, the client just says, give me the
resource. The server always serves the most "recent" version. In the
case of skins, it would serve only the "current" skin.

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
|  5 Business days til JSF 2.2 Public Review to EG