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/