Hi,
>>> 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?
+1 to "skip" skinning and make it part of "Multi-Templating"
I am not really happy with that term (Template already being ambiguous in JSF), maybe we can find something better? Resource-Modules? Theming? ….
> 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?
+1 (I'd even love to see this for composite components - we probably have to "work" on the caching then, but still…)
> 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:
I always like as basis an approach which can be coded, as is with ResourceHandler.getDefaultLibraryName(FacesContext), but maybe we should have: List<String>/String[] ResourceHandler.getDefaultLibraryNames(FacesContext ctx or whatever we need to map the libraries), which should then be checked one by one, so in your example that could be:
["mobile_dark","mobile"] so with resource css/main.css we get the following search order mobile_dark/css/main.css => mobile/css/main.css => css/main.css
This way we get "theme extension".
Concerning: (From Ed Burns logged work at 22/May
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971)
> A multi-template is specified as a resource
> library that includes the file template.xhtml in its top level. Every
> Facelet VDL view in the application will be a template-client of this
> template. PENDING: there must be some way for an application to express
> which views should have the multi-template applied. Perhaps some kind of
> pattern matching system?
Why automatically make template.xhtml the "template-host" of every VDL-view, why not use what we already have:
<ui:composition template="/{theme}/shoppingtemplate.xhtml">
Doing so (with the ResourceHandler.getDefaultLibraryNames from above)
a) We don't need pattern matching or other configuration options
b) One can pick different base templates of the Theme/Multi-Templating for different "sections" of the site.
c) We are - as far as I can see - done, if we change the ResourceHandling appropriately and use that for template discovery.
As the requested Facelet VDL needs to be written as a template-client anyway, I don't see a drawback in having to use <ui:composition> explicitly.
Just my two cents :)
Imre
Am 12.08.2012 um 19:36 schrieb Frank Caputo <frank_at_frankcaputo.de>:
> Hi Leonardo,
>
> I changed the topic to fit my answer.
>
>
> 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/
>>
>
>