Hi Leonardo,
I changed the topic to fit my answer.
I think you basically have the same question as me: Why limit this functionality to templates only? You want to be able replace any resource, right?
I think tying it to the library name is a good idea. Maybe we can have something like ResourceHandler.getDefaultLibraryName(FacesContext), which is simply a prefix for all resources requested in the given FacesContext. E.g:
ResourceHandler.getDefaultLibraryName(FacesContext) returns "mobile"
ResourceHandler.createResource("main.css", "css") becomes ResourceHandler.createResource("main.css", "mobile/css")
If ResourceHandler.createResource("main.css", "mobile/css") returns null, use ResourceHandler.createResource("main.css", "css")
From my point of view there is no need for configuration. If the developer want's it, she should simply create a ResourceHandlerWrapper and implement getDefaultLibraryName according to her needs.
Ciao Frank
Am 06.08.2012 um 00:21 schrieb Leonardo Uribe:
> Hi Ed
>
> Thinking about this issue, I have some comments that could help. Maybe
> there are some concepts you understand better than me, but I would
> like to be sure you have all necessary information, including what we
> have done in MyFaces side.
>
> I agree with you about multi-templating is a super-set of skinning,
> but I think this issue is all about how to map resources.
>
> To define any skin, what you provide is a set of resources (css,
> images, ...) that can be used for an specific renderkit. To define
> multi-templating, you also provide another set of resources (xhtml,
> css, ...). In both, it is necessary to define some "extension points".
> For example, a skin requires define some selectors on the renderkit
> side. A multi-template requires to define an specific page layout
> (header, footer, navigation menu, ....) and so on.
>
> In few words, the big question is how to setup or map those resources.
> One option I tried in MyFaces was do some small changes on
> h:outputScript and h:outputStylesheet. See:
>
> https://issues.apache.org/jira/browse/MYFACES-3355
>
> The change done is quite simple, just consider that after
> ResourceHandler.createResource(resourceName, libraryName) is called,
> Resource.getLibraryName() could return a different value than the one
> passed to createResource() call. In that way, you can create a
> Resource wrapper and override the libraryName.
>
> You can see quickly how useful this can be. If you have multiple js
> files, with this feature you can group all of them, redirecting the
> libraryName and resourceName. This is a nice feature, that requires
> just update some lines in some renderers, but maybe it requires to
> update the spec renderkit javadoc. Anyway, multi-templating/skinning
> requires something else that this hack.
>
> The url provided by a Resource instance to be included in a view or
> page is affected by:
>
> 1. The current locale of the view.
> 2. The multi-templating/skinning configuration of the view.
>
> In other words, a requeriment for any multi-templating/skinning
> solution is that the generated Resource instances should contains all
> necessary information to derive both the locale an the
> multi-templating/skinning configuration, at least for derive the
> Resource instance.
>
> Multi-templating/skinning group resources together in a different way
> than some resources are grouped into a library, because you can expect
> a skin "extends" from other one, but that's not possible for a library
> (not sure about it, it is a controversial topic).
>
> At the end, it is necessary to:
>
> 1. Provide a way to configure multi-templating/skinning in a web
> application (how? xml? like faces navigation? multitemplating/skinning
> configuration looks like the outcome in a navigation?).
> 2. Provide a way to define how a multi-templating/skinning
> configuration for a view affect a created Resource instance.
> 3. Update JSF spec section 2.6.
>
> regards,
>
> Leonardo Uribe
>
> 2012/8/3 Edward Burns <edward.burns_at_oracle.com>:
>>>>>>> On Thu, 24 May 2012 11:01:26 -0700, Edward Burns <edward.burns_at_oracle.com> said:
>>
>> EB> While the discussion about passthrough attributes (including data-*
>> EB> attributes) continues, I'd like to get discussion started on 971-Multi
>> EB> Templating. Here's the commit log for a commit I did on Tuesday. Please
>> EB> take a look and comment.
>>
>>>>>>> On Sat, 26 May 2012 15:34:38 +0200, Frank Caputo <frank_at_frankcaputo.de> said:
>>
>> FC> I think the spec needs a more generic solution.
>>
>>>>>>> On Sat, 23 Jun 2012 17:15:10 +0200, Frank Caputo <frank_at_frankcaputo.de> said:
>>
>> FC> since there are no followups on my mail I'd like to explain my
>> FC> concerns:
>>
>>>>>>> On Mon, 25 Jun 2012 19:28:14 +0200, Frank Caputo <frank_at_frankcaputo.de> said:
>>
>> FC> I'd like to have skinning, which could form the basis for multi-tenancy.
>>
>> Hello Frank,
>>
>> I'm trying to get this one rolling again too. Your mails from 23 and 25
>> June both mention the terms "skinning", "multi-tenancy", and
>> "multi-templating". These are three different things and it's important
>> that we get the terms straight.
>>
>> "multi-tenancy"
>>
>> From the perspective of JSF, I've been looking at multi-tenancy as a
>> capability we put into the hands of developers building on top of JSF.
>> I want to make it possible for people to build an app where per-tenant
>> customizations can be made at deployment time. Mult-tenancy intersects
>> with multi-templating only so much as multi-templating makes it possible
>> to build software where the template actually used can be decided at
>> deployment time, for example. That said, I'd really like to leave
>> multi-tenancy out of the discussion and just keep it as a cross-cutting
>> concern that we validate from time to time.
>>
>> Now, we come to "skinning" and "multi-templating". I've been looking at
>> these as two different things, but I'm concerned it might be harmful to
>> look at them that way. There are areas of overlap between the two
>> concepts. In any case, here's how I see it.
>>
>> Skinning is all about the "look" of the entire app. An app can have
>> only one skin. A skin applies to the entire app and has to do with
>> colors, fonts, rounded corners, images and overall appearance. Skins
>> say how things look, but they don't say where they should go. For
>> example, a skin might make it so the top level menu has a blue
>> background with black text in an Arial-looking font, but it doesn't say
>> if the menu should be on the top, the left, or the right of the view.
>>
>> Multi-templating is about the arrangement of the things within the app.
>> It *does* say where the menu should go. An app can have any number of
>> multi-templates operating within it, some of which only apply when the
>> user is navigating a certain section of the app. I'm imagining a system
>> where there can be a root multi-template, and any number of sub
>> multi-templates.
>>
>> Question: Does it make sense to continue to separate the concepts of
>> skinning and multi-templating, or should we just go ahead and declare
>> right now that multi-templating is a super-set of skinning and stop
>> talking about skinning altogether, just framing the discussion in terms
>> of multi-templating?
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | homepage: | http://ridingthecrest.com/
>