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

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

From: Frank Caputo <frank_at_frankcaputo.de>
Date: Thu, 12 Jul 2012 17:53:34 +0200

Hi Ed,

Am 12.07.2012 um 16:45 schrieb Edward Burns:

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

Ok, I didn't know this. I didn't even find in the spec, that rendering the version is strongly discouraged. So I took a look at Mojarra and it actually renders the version (see ResourceImpl line 284-293).

Then we should spec that versions should not be rendered and fix Mojarra.


Ciao Frank