• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Will we ever see compatiblity between different component libraries?

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agree and it is obvious that JSF lacks the good concept from the very beginning
 
Rainer Eschen
author
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
reply
    Bookmark Topic Watch Topic
  • New Topic