MyFaces + Facelets vs. Shale
At some point, I plan on replacing the JSF+JSP combination in AppFuse with JSF+Facelets. However, I'm wondering if this is just an interim step to a more full-featured framework like Shale and its Clay templates.
Has anyone out there tried both Shale and MyFaces+Facelets? If so, which one worked best for you?
Should we use Shale for the JSF framework in AppFuse or is MyFaces + Facelets good enough?
Can JSP-based components (particularly Ajax ones) be used with Clay and/or Facelets? What's the best Ajax-enabled component library available for JSF? I know there's more everyday, so I'm looking for first-hand, real-world experience here. Thanks in advance for any advice or stories you'd like to share!
http://www.ajaxjsf.com
I started out looking at Trinidad and Tobago, but documentation was very hard to find. Maybe it is out there, somewhere, but I just couldn't find any.
Then I spent some time looking at Sun's BluePrints components. They are much better documented, but deployment was a nightmare! First you had to download all of GlassFish (!), then build the BluePrints components, then finally you could possibly add them to your own environment. Which is pretty daunting. What finally made me abandon BluePrints was a look at their mailing list archive:
https://blueprints.dev.java.net/servlets/SummarizeList?listName=users
In all 33 messages in over a year! Which means it is DEAD.
Next up from my viewpoint (I'm only looking for open source or free as beer frameworks) was ICEfaces. Very well documented, and I found just the component I wanted to try out - the Sortable Header component that can be found on this page:
http://component-showcase.icesoft.com/component-showcase/
I never got it working inside AppFuse, but got it working just great in a standalone Tomcat setup. I wouldn't blame AppFuse really, since it could be just me.
Anyway, from my standpoint, ICEfaces looks pretty solid to me, even though there are unresolved glitches. For example, it works at home on a brand new release of Tomcat, but doesn't load when I deploy at my commercial hosting provider.
Mats
Posted by Mats Henricson on October 07, 2006 at 03:52 AM MDT #
Posted by Jacob Hookom on October 07, 2006 at 09:05 AM MDT #
It's something to keep an eye on anyway and I'm sure that both Clay and Facelets will support.
Posted by Gary VanMatre on October 08, 2006 at 06:45 AM MDT #
Facelets is great because it is very lightweight in terms of required setup and will immediately lead to a reduction in UI code. It eliminates the need for the most common JSF tags used under JSP, which are f:verbatim and h:outputText. Additionally, it adds functionality familiar to those coming from JSP. This means that you get core JSTL functionality like conditionals, variable assignment, page includes, loops, and any JSTL-like function you can dream up.
However, without question, the most powerful and beloved feature of Facelets is the composition tag. While this tag enables you to make common templates similar to tiles or struts template, that merely describes the surface. Digging deeper, compositions can be loosely compared with the lamda function in lisp. It is possible to assign any XML tag to a template, which will interpet the XML attributes as parameters and execute very much like a function call. By doing this, it is essentially possible to "compose" renderers for tags right inline with Facelets syntax. If you want to create a calendar tag, for instance, it simply becomes a template, and all the logic is stuffed into a file in the web directory and represented by an appfuse:calendar tag. I highly recommend Rick Hightower's developerWorks articles on Advanced Facelets Programming to see this in action.
Moving on to the AJAX question, I believe that your programming style will best align with the Ajax4Jsf project. The approach of Ajax4Jsf is a declarative one. Using XML tags, you can indicate which portions of the page should be updated in response to actions or events. Any tag can be made Ajax aware using this declarative model. Combining Ajax4Jsf with Facelets compositions allows you to hide the implementation details of the Ajax functionality, so later you could go and write a full blown component, with no need to modify the original page. If you can't like that, I don't know what you can.
As a final note, I would be somewhat skeptical about the Oracle ADF library, now belovedly known as Tobago. It is currently in the Apache Incubator. All of those components use the Oracle direct rendering techology, which means the use of iframes to communicate asynchronous requests. No XMLHttpRequest. So to conclude, Facelets+Ajax4Jsf.
Posted by Dan Allen on October 08, 2006 at 07:56 AM MDT #
What I don't like so much about Facelets is, that the tags aren't strong typed, so basically, you can add every attribute you like to a tag (or leave it out), unless you're writing a custom taghandler, that checks for the existence of the attributes. It would be nice if it was possible to add some meta-information about supported attributes to the Facelets-taglib, so that IDEs could use it to assist with code-completition. Exadel Studio claims to support Facelets auto-completition, but this works only through adding the jsp-tld ;) Same goes for the composition feature. How can someone know about the supported attributes of a composite-tag if he didn't write it himself? And digging into the jars, where the composition-fragment can be found, shouldn't be the way..
I didn't have a closer look at Clay, so I can't comment on this. I think Clay can do almost similar composition tasks as Facelets, but requires a lot of XML description (huh, the thing I was complaining about Facelets.. ;) ) and JSP.
ICEFaces doesn't have the same approach as ajax4jsf and DynaFaces have. ATM you have to follow their component-model to get the benefits of the Direct2Dom technology, so hooking up components of other libraries together with the ICEFaces components isn't possible (till now), as they cannot re-render arbitrary components through their renderkit. (see ICESoft support forum)
To Trinidad (not Tobago ;) ): What's so bad after all with the iframe-approach? Are there any major drawbacks in comparison to XHR, if you don't have to implement the communication yourself but can instead rely on the framework (Trinidad)?
To DynaFaces (jsf_extensions): I think that DynaFaces is not really aimed at ajaxifying existing components or applications (although you can define ajax-zones to be refreshed). Instead one should use its features for custom-component development, so the component-assembler won't have to add ugly javascript code later on. ATM, DynaFaces doesn't shield you as much from javasript as ajax4jsf does, but gives you more customization-options, am I right there? For more fine-grained ajax-functionality one would have to come up with Mabon or Shale Remoting and integrate it with JMaki wrapped widgets...
There are so many approaches out there, crazy ;) But for the ajax-enabled framework, I would go for ajax4jsf, too (and DynaFaces for custom component development with focus on jsf 1.2 implementations) greets!
Posted by Clemens Schneider on October 08, 2006 at 12:38 PM MDT #
Posted by Dan Allen on October 08, 2006 at 06:51 PM MDT #