Multi-templating System

[glassfishrobot]

give to a JSF application, the ability to change its look and feel with the use of several templates

Affected Versions

[2.2]

[glassfishrobot]

Reported by lamine_ba

[glassfishrobot]

lamine_ba said: Our multi-templating system will be made by several templates and each template will come with its own index file. A JSF application will be able to change its look and feel because each template will come with its own resources (css,js,images), a thumbnail for one to see what it looks like and its metadata.

Template Reference in a view

<ui:composition template="#

{template}

"> </ui:composition>

Template Structure

• templates
  • joomswanky
    • css
      • template.css ( default skinning file)
    • images
    • js
    • template.png (thumbnail)
    • template.xml (metadata)
    • template.xhtml (facelets template)

Template Metadata (template.xml)

[glassfishrobot]

@arjantijms said: This is a really interesting idea...

[glassfishrobot]

lamine_ba said: This concept is another form of skinning (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-316).

You can try the prototype here : http://jsfmtsystem.appspot.com/

and You can read more about it here :

http://weblogs.java.net/blog/lamineba/archive/2011/08/28/multi-templating-jsf-2-prototype

[glassfishrobot]

rdelaplante said: I have implemented a similar concept in JSF as well. In my experience you need a hierarchy of message resource bundles as well. You have a global system bundle for the majority of messages, and a template/brand/theme specific resource bundle that can override any of the global system messages, as well as add additional messages needed by the template/brand/theme (for their header, footer, etc.) You also need to take into account images that have text on them and need to be localized.

Also, we have created a .xhtml facelet file for every screen of our application in each template/brand/theme directory. It's not just the header/footer that changes... the way they want to lay out panels looks different, their placement of buttons, etc. We need to make our application look exactly like the customer's existing website so their customers don't realize they have gone to another site for our particular workflow. Every customer is totally different.

One more comment... every resource used by our template/brand/theme is listed in a configuration file so that when a web user requests it, we can make sure they are allowed to read that file and don't try to hack the system by doing things such as ../../../../. When I say resource, I'm talking about images, JavaScript files, CSS files, etc.

[glassfishrobot]

cappi said: rdelaplante is absolutely right:

It's not just the header/footer that changes... the way they want to lay out panels looks different, their placement of buttons, etc. We need to make our application look exactly like the customer's existing website so their customers don't realize they have gone to another site for our particular workflow. Every customer is totally different.

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.

[glassfishrobot]

lamine_ba said: It seems that in 2012, multi-tenancy is the new buzzword in JSF 2.2 when myself I created a multi-tenant SAAS application level 4 in 2007 with JSF 1. x. And based on this difficult experience, I can assure you that with just your faces flows and this little feature I have donated to JSF, you'll never be able to reach this level. Now to answer these comments above, a multi-templating system does not mean to take a generic template and make it fit to all your customers. That is where the mistake starts and ../../../../ is impossible to do in JSF 2 if you understand very well how its resource handling works.

Also the first and simple requirement for a framework to have multi-tenancy capabilities is to first scale...

[glassfishrobot]

rdelaplante said: I respectfully disagree. I have also created a multi-tenant SAAS application in 2007 with JSF 1.x and continue to maintain it today. The whole point of multi-templating is to be able to style the web application the way the customer wants, which with my customers, is always to make it look like their existing website. I keep a runtime data directory outside of the .war file, on the filesystem, and it includes multiple "themes" for customer brands including desktop and mobile themes. That is why MY custom facelet resource resolver reads from the filesystem and needs protection from ../../../../ by using a theme configuration file that lists which resources to make available. When discussing this with JSF people years ago they thought it was totally wrong to use the filesystem. I completely disagree because I should not have to do custom builds of my application for each customer. One build works for all customers, and their "runtime data" including HTML/CSS/images/email templates/language files/log files/configuration/etc. all lives outside of the application, as it should. They can make tweaks to their templates and have it take effect immediately. When I deploy the latest version of the .war, they do not need to touch the runtime data directly unless they want to add support for a new software feature in their theme templates.

[glassfishrobot]

lamine_ba said: And myself I respectfully agree to any of your comments. And here is how life is, full of diversity and full of contradictions. We no longer share the same vision, nor the same goal, nor the same requirements. And that is why I have waited a long time before answering.

I think it is better now for the JSF EG to keep just the idea and design it based on your visions. Myself here is how my multi-templating system is designed (back-end, front-end support....) and if you watch carefully at its video, you will read its well-defined slogan : Design and share your templates through REST. It was self evident that JAX-RS was on my mind.....

1) http://youcontrol.lamine.cloudbees.net/faces/admin/templates/ 2) http://www.youtube.com/watch?v=6t-xB8wP8Rg

Thank you very much for your nice comments, I have really learned a lot from you.......

[glassfishrobot]

lamine_ba said: rdelaplante>That is why MY custom facelet resource resolver reads from the filesystem and needs rdelaplante>protection from ../../../../

I understand now what you mean. I thought you were talking about the ResourceHandler.

rdelaplante>When discussing this with JSF people years ago they thought it was totally wrong to rdelaplante>use the filesystem

I have ever used this strategy and I will continue to use it because you and I, we know the value in it but sadly the vision of the JSF spec lead is to store your templates in a jar.

http://jaxenter.com/interview-with-jsf-spec-lead-ed-burns-41883.html

[glassfishrobot]

rdelaplante said: You have obviously put a lot of thought and effort into your design, and it's great that you are contributing to the JSF spec. I've been meaning to join the JSF EG to standardize the Tomahawk radio button for years after realizing that making noise about it doesn't seem to be convincing enough to them. Someday when I have more time I will need to look through your work in more detail, as well as the JSF EG's refinements. Surely there are good ideas in there. What I created was based on my app's requirements, so I don't know how other people have approached the problem, especially from JSF perspective. Regarding .jar vs filesystem... who knows, there may be a very good reason why the EG prefers this approach that we never considered. Maybe they are thinking ahead to the Java 8 module system which might enable us to dynamically reload modules at runtime. We should ask.

[glassfishrobot]

lamine_ba said: Yes that is right : Since 2005, I have put a lot of thought and effort in my obsession to build a clone of the multi-templating system of Joomla : http://docs.joomla.org/Introduction_to_Joomla!_templates.

Reading just your comments, you would have been a wonderful Expert if you had joined the JSF 2.2 EG. Myself I was a member of this EG but sadly I have now no time for JSF. But as a farewell, I thought it would great if I could leave them with this idea....

[glassfishrobot]

rdelaplante said: Just curious... when you say you have no more time for JSF, and are saying farewall, does that mean you will no longer be using JSF in any future projects? If yes, what will you be using?

[glassfishrobot]

lamine_ba said: We are in the midst of a paradigm shift that will dramatically change how many of us build and deploy software. The age of server side UI framework is over since the client side is now powerful and mature. Modern web application architecture moves the UI to the client, where all user interactions are handled on the client-side. All UI state, too, moves to the client-side. The client then just makes calls to the server when it needs to access shared data or communicate with other clients / systems. The client talks to the server through HTTP using a RESTful pattern or possibly the newer WebSockets protocol which allows for bidirectional communication.

I have built a web framework for JAX-RS on top of JSF in the goal to run it in a stateless mode and reuse Facelets , the resource handling and the composite components features:

for more information, read this

1)http://weblogs.java.net/blog/lamineba/archive/2012/04/10/if-jax-rs-had-mvc-framework 2)http://weblogs.java.net/blog/lamineba/archive/2012/05/20/building-restful-web-services-jax-rs-jaxb-and-groovy

[glassfishrobot]

gonzalad said: I'm currenlty using Seam theme (http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/i18n.html#d0e14307) to handle multiple themes in some applications.

I would like to know about the following notions are likely to be integrated in this ticket:

1. Theme parameters Are you going to 'standardise' theme configuration ? Something like : http://docs.joomla.org/Template_parameters for instance a theme could require general color or xhtml/html5 configuration parameter. Can we use the same theme multiple times in the same application but with different configurations ?
2. Theme inheritance For instancen we have a company A theme. We need to create a theme for a subsidary company (which is similar to company A theme). I would like to customise theme A to create theme B. Would it be possible without copy/paste ?
3. Theme selection Theme selection algorithm must be pluggable (i.e. from HTTP parameter, from cookie or whatever)

[glassfishrobot]

@edburns said: Deferring this to a later release.

[glassfishrobot]

File: screenshot-1.jpg Attached By: lamine_ba

[glassfishrobot]

Sub-Tasks: JAVASERVERFACES_SPEC_PUBLIC-316

[glassfishrobot]

Issue-Links: depends on JAVASERVERFACES_SPEC_PUBLIC-948 JAVASERVERFACES_SPEC_PUBLIC-532 blocks JAVASERVERFACES_SPEC_PUBLIC-1051 JAVASERVERFACES_SPEC_PUBLIC-1047 JAVASERVERFACES_SPEC_PUBLIC-1046 JAVASERVERFACES-2511 is related to JAVASERVERFACES_SPEC_PUBLIC-1142

[glassfishrobot]

This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-971

[glassfishrobot]

Marked as won't fix on Thursday, November 8th 2012, 9:39:01 am