Am 28.06.2012 um 16:02 schrieb Kito Mann:
> 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.
All clients of mine, who wanted a skinning solution, wouldn't be happy with the original proposal, because it is just replacing the template. They all wanted to be able to replace any resource, without any limitations.
Ciao Frank
>
>
> 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
>>