This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I've played around with Icefaces, Myfaces and PrimeFaces and like various apects of each but I am restricted to IBM faces at work. IBM faces is ok, it solves a few problems quite well and it intergrates with RAD really well, it's just new components are rare and lacks nice UI things like effects, tooltips and lightboxes.
Do you think we will ever see compatiblity between different component libraries? or is the way in which JSF works prohibit this? for example so I could use a <ice:inputRichText> inside a ibm <h:form>
The core JSF tagset should be 100% compatible - it's part of the JEE specification. The nominal namespaces for the core tags include the "h:" namespace (as in "<h:form>") and the "f:" namespace.
It's harder to make the extension tagsets be 100% compatible because they often create a fairly complex infrastructure that only other members of the same tagset (or other tagsets from the same source) are designed to interface with.
Good practice is that when you extend functions from the core tagsets that you retain some compatibility, but that can be tricky sometimes. I believe, for example, that RichFaces once required an "a4j:form" in order to properly house certain of their functions, but they eventually found a way to fold what they needed into something that could like under the standard core form (h:form) element.
An IDE is no substitute for an Intelligent Developer.
Scott Bown wrote:I've played around with Icefaces, Myfaces and PrimeFaces and like various apects of each but I am restricted to IBM faces at work
Do you think we will ever see compatiblity between different component libraries? or is the way in which JSF works prohibit this?
Dear Scott Bown, unfortunately your company's rule restrict you to use anything else than IBM faces.
So, won't help you too much any interchangeability of different JSF implementations.
I was involved in a development team where I saw that they started with MyFaces, then later switched to IceFaces. Everything in portal environment, and while some MyFaces portlets still working they are constructed new ones with IceFaces.
Joined: Sep 06, 2007
Tibi Kiss wrote:unfortunately your company's rule restrict you to use anything else than IBM faces. So, won't help you too much any interchangeability of different JSF implementations.
Restrict is probably a little strong, I mean the core developerment will probably stay in ibm faces for now but I wanted to use different component libraries at the same time. Interchangeability is helpful if we move away from ibm faces to something like iceFaces / primeFaces.
The standard JSF stuff should work. But, really annoying is the missing standardization in the AJAX add-ons. So, if two JSF frameworks don't share the same AJAX frameworks you can stop your integration ideas. But, if you have a look at the 1.8 ICEfaces architecture you recognize that even using the same AJAX frameworks doesn't help in any case. All this AJAX (Push) communication stuff is so complicate these days that we have to wait for the vendors to deliver a JSF framework integration. ICEfaces is doing this for Tomahawk (with limitations).
I hope that JSF 2.0 defines enough standard in the AJAX playground to get better results in the future. Today you have to select the one and only framework and hope that you get enough support in all your integration needs.
ICEsoft is doing a pretty good job in the integration with other frameworks, app servers, IDEs, etc. Maybe this helps a bit for a decision.
One of the things that became apparent as JSF evolved was just how much out-of-line generation a good framework demands, and how different subsystems can get into fights over who needs to be first in the queue. At the moment, it's sort of an uneasy truce.
However, it's my understanding that JSF 2 is supposed have expended a lot of effort on civilizing that state of affairs. How well it worked, we'll see. Now if they'd only do something decent about session timeouts. Especially session timeouts on AJAX requests, but really all session timeouts. Even with JSF2, what I've seen to address that common problem has been pretty ugly.
Agree and it is obvious that JSF lacks the good concept from the very beginning
Joined: Jan 24, 2009
John, maybe. You have to remember that the ideas for JSF are from about 2002. That's 7 years now and about 4 computer generations away ;-). Nobody thought of AJAX and server-side Push renderings those days. Compatibility to JSP/Struts was important (the father of Struts did the lead as far as I remember).
Thank God, JSF 2.0 is right before production. So, we will soon get what we expected over the last years twiddling with AJAX in context to JSF.
Although from the desktop developers point of view I totally have to agree. Although we talk about components and events even the most modern implementation of JSF is pretty ridiculous in comparison to a VB or Delphi 3/4 programming model from the mid/late 1990s. But this was also true for Swing development for a long time. Netbeans/Matisse was the first tool I really could have a comparison with a Delphi 3.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Will we ever see compatiblity between different component libraries?