Hello Frank,
Perhaps we need to clarify exactly what the goal is: provide skinning, or
multi-tenancy, or both?
I've certainly had clients that needed to provide per-client customization,
but not necessary multi-tenancy.
___
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. |
http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x246
* Join me at JAXConf with JSF Summit July 9-12 in San Francisco (JSF,
Android, Cloud, Big Data, Java EE, and more):
http://jaxconf.com/2012
* Listen to the latest headlines in the JSF and Java EE newscast:
http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
On Sat, Jun 23, 2012 at 11:15 AM, Frank Caputo <frank_at_frankcaputo.de> wrote:
> 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/
>
>
>
>
>
>