Hi Experts,
since there are no followups on my mail I'd like to explain my concerns:
The Multi-Templating feature as proposed is a feature which is very useful for a CMS. So if someone produces a CMS on top of JSF, she might add such a feature.
The proposal is actually insufficient for real multi tenancy as the inventor of this approach stated here (and I totally agree):
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971?focusedCommentId=340383&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_340383
I simply repeat, what I said before:
-----------snip-----------------------------------
I also implemented something similar called skinning with JSF 2.0. I extended ResourceHandler, ResourceManager, ResourceResolver and the FaceletFactory. This way we were able to replace every single facelet (eg. includes or templates). We could replace resources and thereby even composite components.
It used convention without any configuration. With the following directory structure:
\--folder
\--sample.xhtml
\--skins
\--foo
\--sample.xhtml
\--resources
\--logo.png
\--skins
\--foo
\--logo.png
The skins folder inside the resources folder was a compromise because resources is quite hardcoded. It would be nicer to have skins/foo/resources. If we add resource bundles to this skinning, we have real multi tenancy.
I think the possibility to replace every single facelet and resource is essential for multi tenancy. Because sometimes it is done by replacing a logo and a login box for example for SSO or whatever. In other cases you must replace some composite components, because the UX of the tenant uses other metaphors, but the placement on the page stays the same as for all other tenants.
And i think this way is more object/component oriented.
-----------snip-----------------------------------
Since we are loading facelets with the ResourceHandler we simply need to make the ResourceHandler skinnable. The ResourceHandler should fall back gracefully, if no skinned resource/facelet is found.
The skin should be determined via FacesContext.getCurrentInstance().getSkin(). (do we need a complex object for the skin or is String sufficient?)
I think we don't need to provide a default implementation to detect the skin, because there are a lot of ways, how to build multi tenancy (e.g based on the hostname or the logged in user or the time of day). To detect the skin, the developer could simply decorate the FacesContext and do whatever she wants.
Ciao Frank
Am 26.05.2012 um 15:34 schrieb Frank Caputo:
> Hi EG,
>
> I think the spec needs a more generic solution. Please take a look at the last 2 comments on the issue: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971?focusedCommentId=329449&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_329449
>
> If anyone else agrees to the comments, I can refine my comment on this.
>
>
> Cheers,
> Frank
>
> On 24.05.2012, at 20:01, Edward Burns <edward.burns_at_oracle.com> wrote:
>
>> While the discussion about passthrough attributes (including data-*
>> attributes) continues, I'd like to get discussion started on 971-Multi
>> Templating. Here's the commit log for a commit I did on Tuesday. Please
>> take a look and comment.
>>
>> SECTION: Modified Files
>> ----------------------------
>> M integrationWithFacelets.fm (the Facelets chapter)
>>
>> - New section: Multi-templating
>>
>> JSF defines a system called "multi-templating" for applying templates to
>> an entire application. 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?
>> [P1-start_facelet_multi_template_inclusion]Implementations must make it
>> so that, effectively, the multi-template is equivalent to having a
>> <ui:composition> around every view in the application where the template
>> attribute of that <ui:composition> refers to the template.xhtml
>> file.[P1-end_facelet_multi_template_inclusion]
>>
>> Identifying the Multi-Template
>>
>> PENDING: do we need to support a list of multi-templates that must be
>> applied, or is one enough?
>>
>> The multi-template to apply to the application is identified by means of
>> the javax.faces.MULTI_TEMPLATE <context-param>. If such a parameter
>> exists its value is taken to be the name of a resource library
>> multiTemplate. Otherwise, the value of the symbolic constant
>> ResourceHandler.DEFAULT_MULTI_TEMPLATE is taken to be the name of a
>> resource library multiTemplate. If a library named multiTemplate is
>> accessible to the application, and it contains a resource named
>> template.xhtml, that resource is assumed to be suitable for use as the
>> template for an implicit <ui:composition> that is made to be the
>> template for every Facelet VDL view in the application. Otherwise, the
>> multi-templating feature is effectively disabled for the application.
>>
>> M usingFacesInWebapps.fm
>>
>> - Reference the new context-param
>>
>> M preface.fm
>>
>> - reference changes in other files
>>
>>
>> M jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
>>
>> - Add new context-param.
>>
>> M jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
>>
>> - Context params related to multi-templating
>>
>> + /**
>> + * <p class="changed_added_2_2">If a
>> + * <code><context-param></code> with the param name equal to
>> + * the value of {_at_link #MULTI_TEMPLATE_PARAM_NAME}
>> + * exists, the runtime must interpret its value as the name of a resource
>> + * library that conforms to the naming conventions of a multi-template.</p>
>> + * @since 2.2
>> + */
>> + public static final String MULTI_TEMPLATE_PARAM_NAME =
>> + "javax.faces.MULTI_TEMPLATE";
>>
>> + /**
>> + * <p class="changed_added_2_2">The name of the default multi-template
>> + * to look for in the absence of a value for {_at_link #MULTI_TEMPLATE_PARAM_NAME}.</p>
>> + * @since 2.2
>> + */
>> + public static final String DEFAULT_MULTI_TEMPLATE =
>> + "javax_faces_template";
>>
>> M jsf-ri/src/main/java/com/sun/faces/facelets/compiler/SAXCompiler.java
>>
>> - Implement the requirement to apply a default template to every page if
>> a multi-template exists for the current web app.
>>
>> M jsf-ri/src/main/java/com/sun/faces/facelets/tag/ui/CompositionHandler.java
>>
>> - As an implementation detail, the value of the "template" attribute
>> will be an instance of java.net.URL in the case of the the synthetic
>> <ui:composition> inserted when the application has a default template.
>> Account for this change.
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | homepage: | http://ridingthecrest.com/
>>
>