Skip to main content

JSF 2.2 contracts - templates on filesystem

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
No replies
rdelaplante
Offline
Joined: 2007-04-01

In our system, each customer's theme styles the application to look & feel like their corporate website so that our application feels like part of their existing website. The application was originally written around 2006 - 2007 using JSF 1.x and we had a requirement to externalize the Facelet templates, images, CSS files, JavaScript files, etc. to the filesystem so that we are not building a custom .war bundle for each and every customer. I developed a solution based on a custom resource resolves, and it works well.

The developer who created the original multi-templating proposal also developed a similar solution on JSF 1.x back in 2007 that stores the templates outside of the application, on the filesystem.

I remember having a discussion about this with a JSF EG member back when I originally developed my solution, and he basically said the EG thinks externalizing templates to the filesystem is a bad practice. When we brought this up during JSF 2.2 development (multi-templating feature), again we got basically the same response and instead they will support putting templates in .jar files that can be versioned etc. I can see the usefulness of that, but look at it from my perspective. Do you really think it is a best practice to build a custom .war file for each and every customer that includes their .jar file and excludes the .jar files of other customers? What if the customer wants to make tweaks to it? Explode the .war file, find and extract the .jar file, make your changes, bundle it all back up and redeploy?

I'm evaluating the new JSF 2.2 multi templating feature for a new project right now and generally like the design, except for one fatal flaw: I can't store the templates on the filesystem! I'm going to look into developing a custom resource resolver that looks for "/contracts/". If I can't solve this problem, then the multi-templating feature will be un-usable for me and I will need to develop a custom solution again.

This reminds me of another issue that I've brought up multiple times since around 2006 - 2007: the radio button component is useless. It renders itself in a table and doesn't let me sprinkle the buttons wherever I need in the template. The Tomahawk t:radio button is an elegant solution that should have been integrated into JSF. I suggested this for JSF 2.2 and still, seven years later, JSF lacks a fundamental feature of the web.

This kind of stuff frustrates me to no end. I really like how JSF has progressed, think that I have legitimate concerns, but feel ignored by the experts.