> I searched the threads on this forum but didn't find any discussion on > comparing Wicket with ZK (www.zkoss.org/), the #1 Ajax project on > sourceforge.net now. I read a lot on both frameworks and they both seem nice > from the feedback of the users. Since I am about to choose one web > framework, I want to get some ideas of these questions here.
The main idea behind Wicket is to provide a plain old Java programming model, and this is very different from declarative, DSL based frameworks like ZK (though ZK has an 'advanced mode' where you can write components using Java). Most telling is maybe this quote: "TY: Echo2 assumes UI designers are Swing programmers, while ZK assumes many of them are not programmers. ", from ZK's creator in an interview you can find here: http://blogs.pathf.com/agileajax/2006/06/an_interview_wi.html. Wicket assumes that UI designers are *designers* (and not half-programmers like ZK assumes) only dealing with laying out, and that UI logic can best be coded in Java (by programmers obviously). Wicket enforces a rigid separation of those concerns (presentation and logic), not because we are born zealots, but because most of us have gone through the experience of how easily you can pull your project in the swamp by even allowing for minimal scripting. In that respect, ZK is counter to what we stand for if you look at the database code here: http://www.zkoss.org/doc/tutorial.dsp Don't get me wrong, I think ZK has a couple of nice features. I'm not crazy about XML, but choosing XUL makes sense from their perspective, and the first part of their tutorial which builds up the lists actually looks nice (though you could achieve the same by e.g. picking up http://developer.yahoo.com/yui/datatable/ with whatever server side framework you like). > 1. Design concern (Wicket vs. ZK) > Both frameworks are thin-client and generate AJAX, the biggest difference is > Wicket uses Java and HTML while ZK uses XUL or other scripting language. > What's the advantage and disadvantage in both cases? Advantage of HTML is that you can work with web designers & standard tools for laying out and that you have very direct control of what will be in your users' browsers. XUL might be nice if the framework can decide to send it directly to the client if that supports it. Note btw that Wicket is not an Ajax framework. It has - I believe - excellent Ajax support, but you can build web applications without any Ajax just fine. > 2. AJAX components (Wicket vs. ZK) > From the demo websites, it seems ZK provided more AJAX components than > Wicket. (As I haven't worked deeply with Wicket, it could be Wicket either > provided more components or easy to write those components.) But I am > wondering is it easy to use Wicket to implement features like drag and drop, > date picker... I think it is more relevant to first look at how easy it is to create your own, and second look at exactly what components you need and which are supported. > 3. Target application (Wicket) > There is a trend to move from multi-page application to single-page > application (or a few pages which much lesser than traditional page-based > web application) using AJAX. As far as I know, Wicket is a component-based > framework and very OO, which means the components could be well reused and > maintained, but is it easy to build such single-page application? Would one > or a few more page classes be very large? Whatever you want. No, they wouldn't be large, as you would design panels for sections of a single-page app, and add/ replace those panels based on app logic. > 4. Integration (Wicket) > How about using Wicket together with existing JSF application? There are no such facilities atm, though if you google you should be able to find a couple of examples of where people mixed JSP & Wicket. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
