JBoss Seam unifies several technologies to provide a powerful application framework on web but it also limits your applications technically to use JSF components as the only "view" choice. You now have at least one more choice on developing your Seam web applications. In the article "How to Integrate ZK with Seam," Dennis Chen demonstrates two ways to integrate the ZK Ajax Rich Client framework with Seam based on a JSF example. The first one replaces the JSF pages with associated ZK pages but keeps "Using the bean contexts and navigation rules of Seam." The second one replaces JSF pages with one consolidated responsive ZK Ajax page but keeps "Using bean contexts of Seam only". The validation patterns, navigation flows, and persistence mechanisms of Seam are kept as is. Seam has been designed to eliminate complexity at the architecture and the API level while ZK does not only allow for more pleasing, powerful UIs, but also aid in applying an "Agile" development methodology. Will it make developing rich Ajax web applications simpler and faster by stitching these two "simple" things together? Message was edited by: joeo@enigmastation.com

I always get a kick at how relentless the programming community is at trying to "do away" with page design when it comes to web applications. The fervor of these efforts is entertaining - as though many had been suffering from some malaise and then hallelujah! No more HTML authoring is needed! :-) Why don't you just hire a Web designer? Ian JSFToolbox for Dreamweaver http://www.jsftoolbox.com

The ZK Explorer demo doesn't seem to work very well with Firefox.

Upon a very cursory glance, I can't really see the benefit of using ZK instead of a an AJAX JSF component suite. It's a little more flexible in terms of how you integrate your application logic, but at the end of the day you're still defining your view in XML and binding it to server-side event listeners... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *

Upon a very cursory glance, I can't really see the benefit of using ZK instead of a an AJAX JSF component suite. It's a little more flexible in terms of how you integrate your application logic, but at the end of the day you're still defining your view in XML and binding it to server-side event listeners...

I'm building an application with ZK right now and thought a bit on this very topic before I chose ZK. The truth is, had I found a single AJAX JSF framework that offered a component set as complete as the one ZK offers, I would have gone that route. They do both use XML at the end of the day, but I will tell you that ZK uses *alot* less XML than many/most JSF components. But that's not a huge deal in itself. I liked what I've seen from IceFaces and a few others, but again, their component suites didn't seem as good as ZKs and , whether this is accurate or not, all of the horror stories I've heard about people trying to integrate components from multiple JSF vendors has put me off a bit on that option. Mike

whether this is accurate or not, all of the horror stories I've heard about people trying to integrate components from multiple JSF vendors has put me off a bit on that option.

Mike

My design and development team and I have been successful at integrating components from multiple JSF vendors in our production sites. At the moment, we use JSF Core/HTML, Facelets, Seam, Tomahawk, and Trinidad tags and they all play very nicely together. This is the same approach our tools are built around - we apply Web design principles to JSF and it works well. One of the key benefits of this approach (aside from cleanly separating the concerns of presentation vs. business logic) is that you don't have to throw the baby out with the bathwater if one of the component libraries you are using fails to meet expectations. You can simply swap it out for a better component library. Isn't that the idea behind component-based development? Ian Hlavats JSFToolbox for Dreamweaver http://www.jsftoolbox.com

whether this is accurate or not, all of the horror stories I've heard about people trying to integrate components from multiple JSF vendors has put me off a bit on that option.

Mike

My design and development team and I have been successful at integrating components from multiple JSF vendors in our production sites.

At the moment, we use JSF Core/HTML, Facelets, Seam, Tomahawk, and Trinidad tags and they all play very nicely together.

This is the same approach our tools are built around - we apply Web design principles to JSF and it works well.

One of the key benefits of this approach (aside from cleanly separating the concerns of presentation vs. business logic) is that you don't have to throw the baby out with the bathwater if one of the component libraries you are using fails to meet expectations.

You can simply swap it out for a better component library. Isn't that the idea behind component-based development?

Ian Hlavats
JSFToolbox for Dreamweaver
http://www.jsftoolbox.com

How about integrating those you mentioned with some of the AJAX-enabled component sets like IceFaces? Were there any issues?

How about integrating those you mentioned with some of the AJAX-enabled component sets like IceFaces? Were there any issues?

ICEfaces is next on our list. We haven't crossed that bridge yet, but I'm optimistic.

The component suite looks comprehensive, but using the components in practice feels just as slow as using a web 1.0 site. The problem seems to be that operations which should be handled with javascript take a round trip to server. For example closing a modal dialog box or choosing an entry from autocomplete pulldown brings the 'processing...' indicator to screen, and causes significant lag. AJAX by itself does not necessarily do much good for the responsiveness of web sites. It's the combination of careful use of DHTML and AJAX together that has brought the killer apps. /Henri Karapuu

The component suite looks comprehensive, but using the components in practice feels just as slow as using a web 1.0 site.

The problem seems to be that operations which should be handled with javascript take a round trip to server. For example closing a modal dialog box or choosing an entry from autocomplete pulldown brings the 'processing...' indicator to screen, and causes significant lag.

AJAX by itself does not necessarily do much good for the responsiveness of web sites. It's the combination of careful use of DHTML and AJAX together that has brought the killer apps.

/Henri Karapuu

Agreed on most points. However, this posting back to the server is one of the reasons that building ZK apps so easy - its just Java. Having said that, you're right about this taking longer than a more client-based approach. I think ZK is a perfect fit for intranet type apps. For internet apps with heavy volume, its probably not the best choice yet.

It does take a rountrip to get data from the server for the autocomplete case. But, who doesn't? Unless the list is small, no one affords to load the complete list to the client. Of course, a sophisticated app can do some application-specific caching at the client, like Google Suggests did. As an eneterprise-app developer, I prefer the simplicity and better security that all my codes are running at the server. After all, I don't run website to server millions people. Samia

It's basic for the moment - still waiting for that popular demand ;) - but you can use Seam with Wicket as well. Three choices and counting.