Hi Frank
2012/8/12 Frank Caputo <frank_at_frankcaputo.de>:
> 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?
>
Yes. As I said before, this topic is all about how to map resources.
> 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")
>
It is an option, but it has its advantages:
- It is only required to extend the concept of libraryName.
- No need to update request url spec.
and disadvantages.
- If skinning/templating is built on top of libraryName, no changes in
request url are required, but all limitations of libraryName applies,
like do not allow '/' in libraryName, so the example proposed
replacing libraryName with "mobile/css" is invalid according to
current spec. See:
https://issues.apache.org/jira/browse/MYFACES-3454
for details.
I just wanted to notice that the option is on the table and that any
other strategy has its trade-offs too.
I think any solution should be built to allow:
- Extensibility (theme A extends theme B).
- Packaging (a set of resources together into a single unit)
- Composition (allow multiple units to be dealt as a single "logical" unit).
> 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.
>
I don't know. I think it is worth to deal with the configuration
problem from spec side. Otherwise, each vendor will reinvent the wheel
over and over in this part.
(the following part are just some ideas I have, sorry if the language
is poor or difficult to understand)
I have been thinking on something like faces navigation but for
resources. For an specific view it is defined an "outcome" or
"skin-name" or whatever and there is some kind of algorithm that
defines the order of libraryNames that should be scanned for the
specific resource, just like it is done for a localized resource
(first look for a resource with some specific locale and if it does
exists try to locate it without locale).
Now, suppose you have two different sets of libraries: one for
"skinning" resources one for "layout" resources. The configuration
should be able to say: "if the skin-name is "x" and the libraryName to
resolve is "skinning", the new skin-name is "p" ". If you have the
skins [a, b, c] and layout [x, y] the possible combinations for
skin-name should be [a-x, a-y, b-x, b-y, c-x, c-y]. If it is necessary
to define where is the file for the resource with libraryName "layout"
and resourceName "template1.xhtml" for the skin-name "b-x", both the
skin-name of the current view and the libraryName are passed to some
method, and it founds the rule that says for "b-x" if libraryName
"layout" is passed the new skin-name is "x". At the end, the
libraryName to use for "layout" is "x".
So, we are "splitting" the problem in two (divide and conquer):
- How to resolve a libraryName from a skin-name using some rules,
abstracting "application scope" concepts like skinning, layout and
others.
- How to resolve a libraryName from another libraryName and find an
specific resource, to solve Extensibility, Packaging and Composition.
Will it work? Maybe. It reuse existing concepts found in jsf and it is
simple to do.
Anyway, I don't know what are you guys thinking about this problem.
I'm just trying to provide all information available about the topic,
and specify some "criteria" to evaluate any proposed solution.
regards,
Leonardo Uribe
> 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/
>>
>
>