GeeCON Prague 2014*
The moose likes JSF and the fly likes Will we ever see compatiblity between different component libraries? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » JSF
Bookmark "Will we ever see compatiblity between different component libraries? " Watch "Will we ever see compatiblity between different component libraries? " New topic
Author

Will we ever see compatiblity between different component libraries?

Scott Bown
Ranch Hand

Joined: Sep 06, 2007
Posts: 32
Hi Rainer et al,

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>

Is this something a JSR could help solve?

Thanks,

Scott


Android + J2EE Developer
SCJP 5.0, SCWCD 1.4, SCDJWS 5
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16095
    
  21

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Tibi Kiss
Ranch Hand

Joined: Jun 11, 2009
Posts: 47
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.
Scott Bown
Ranch Hand

Joined: Sep 06, 2007
Posts: 32
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.
Rainer Eschen
author
Ranch Hand

Joined: Jan 24, 2009
Posts: 75
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.


ICEfaces book . ICEcube . ICEfusion . Scrum
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16095
    
  21

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.
Hussein Baghdadi
clojure forum advocate
Bartender

Joined: Nov 08, 2003
Posts: 3479

I wish if the community drop JSF as the standard framework and adopt Wicket instead of it, Wicket is much more decent, light weight and polished framework.
Tibi Kiss
Ranch Hand

Joined: Jun 11, 2009
Posts: 47
Dropping is an individual decision, case by case.

It's harder to drop an existing than pick-up a new one. That's why is very important to have a good concept from the beginning.
Hussein Baghdadi
clojure forum advocate
Bartender

Joined: Nov 08, 2003
Posts: 3479

Agree and it is obvious that JSF lacks the good concept from the very beginning
Rainer Eschen
author
Ranch Hand

Joined: Jan 24, 2009
Posts: 75
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 agree. Here's the link: http://aspose.com/file-tools
 
subject: Will we ever see compatiblity between different component libraries?