On Mon, Jun 25, 2012 at 1:28 PM, Frank Caputo <frank_at_frankcaputo.de> wrote:
> Hi Kito,
>
> I'd like to have skinning, which could form the basis for multi-tenancy.
>
> Ciao Frank
>
> PS: what is the difference between per-client customization and
> multi-tenancy?
>
By per-client customization, I mean installing the same application at
different client sites with a different look and feel (and possibly even
feature set). Multi-tenancy is about having a single deployment support
multiple clients, right?
>
> Am 25.06.2012 um 15:13 schrieb Kito Mann:
>
> 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/
>>
>>
>>
>>
>>
>>
>
>
> -
>
> Frank Caputo
> Johann-Mohr-Weg 24d
> 22763 Hamburg
>
> Mobil +49 177 61 61 81 3
> E-Mail info_at_frankcaputo.de
>
>