On Thu, Jun 28, 2012 at 9:54 AM, Frank Caputo <frank_at_frankcaputo.de> wrote:
>
> Am 28.06.2012 um 15:44 schrieb Kito Mann:
>
> 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?
>
>
> OK. If you have multi-tenancy nobody stops you from having multiple
> deployments of the software. So for me it is quite similar.
>
> Anyway. Both solutions would benefit from a powerful skinning, right?
>
True -- I think skinning/multi-templating is a must. I just wasn't sure we
needed to move beyond the original proposal.
>
>
> Ciao Frank
>
>
>> 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
>>
>>
>
>
> -
>
> Frank Caputo
> Johann-Mohr-Weg 24d
> 22763 Hamburg
>
> Mobil +49 177 61 61 81 3
> E-Mail info_at_frankcaputo.de
>
>