I would encourage you to buy and read Wicket in Action book
instead of looking at Seam vision of Wicket. Wicket is far supperior framework comparing to JSF. Seam and JSF screws up your OOD when Wicket encourages you to do your best with OOD.
It seems every wicket HTML page has a backing class (seems similar to ASP.NET code-behind files). Is this a hard requirement with wicket views? That class must extend org.apache.wicket.markup.html.WebPage and must not be a SFSB. Is this correct?
That's correct in general. Particularly any panel and page may not introduce its markup file (.html part) if the backing class does not add components (say just override isVisible() method from the superclass). It comes in handy for ananymous classes like instance of Link that should override onClick() method.
how to use a dataTable in Wicket? the below html snippet in main.html is very ugly/lengthy in comparison to the JSF/RF equivalent.
I don't know why the sample is so verbose. The regular markup for DataTable is the following:
<table class="dataview" cellspacing="0" wicket:id="table">[table]</table>
columns.add(new PropertyColumn(new Model("First Name"), "firstName", "firstName"));
columns.add(new PropertyColumn(new Model("Last Name"), "lastName", "lastName");
columns.add(new PropertyColumn(new Model("Home Phone"), "homePhone"));
columns.add(new PropertyColumn(new Model("Cell Phone"), "cellPhone"));
add(new DefaultDataTable("table", columns, new SortableContactDataProvider(), 8));
Have a look at DataTable sample
After perusing the entire class, this seems more complicated than JSF/RF but perhaps wicket does not have the life cycle getter/setter multiple-calls problem that JSF has.
That's not correct due to strange Seam sample. Wicket does not have many problems that JSF has not only getters/setters. It has more thoughtout request lifecycle that allows you naturally mount urls to pages instead of using ugly urlrewrite. The list is pretty long. But for now there aren't so much components. From the other hand you can use YUI and jQuery.
Instead of using just one backing bean (e.g. one SFSB) for your view/facelet, now there is an additional class.
Tiering models are the same for Wicket and Seam. Yep you can have one class less with JSF+Seam but you will pay for that when your application grows. The problem is that you don't know the price for now. But the price of having simple java class for backing markup is very cheap (it event isn't worth words I'm typing here). And it is proven since you have separation of concerns. You also have separation of markup and how it is constructed. So it gives you possibility to dinamically decide how to fill it in. The same is pretty cumbersome for JSF and faults with Facelets when you mix parsing and rendering time expressions (that was the reason I moved to opposition to JSF).
What exactly is/are the advantage(s) of using wicket with Seam? How bout the disadvantages?
- Wicket is far faster that JSF (while my pages became twice as complex they are rendered one seconds. I don't know how much. It just present me a page when I click so I did't have to think :) Ajax response is even more faster comparing to RF.
- Wicket generates 3 times shorter html for my pages comparing to JSF/Richfaces implementation. I can use divs instead of wide spread tabs in Richfaces and Icefaces - it allows client browser to render page more quicker. Richfaces produces too verbose output. The css and js files are not cached by browser. It makes response appearing within 3 seconds with RF when I have it immediately with Wicket.
- Wicket pages really suppor backbuttoning, multiple browser tabs and windows. You don't believe. It just works (and should, it is easy to figure out how).
- Wicket has simple and robust AJAX engine. It has html fallback
version of components. For instance you can have AjaxButton that works as
simple submit if the client browser has Javascript switched off.
- Wicket components can be written 100 times faster. The user can start writing components after two hours of reading mentioned book. I could. I designed property editor panel with the label component and input editor choosen by the property type. It was ten times simpler and readable than Facelets version. Don't tell me JSF 2 has a new model for Components. Facelets is evil in my experience.
- Wicket takes into account client locale and timezone.
- Wicket is very good for the model where you separate work of Web Java developers and Web designers. That doesn't mean that they work together all the time. It means Web designer really could help Java developers.
- Wicket is very good for Java developers because it allows to employ OOD practices as you wish. If it sounds simple think about why engineers invented OOD. To overcome growing complexity. So it is the logically that JSF/Seam applications (that can't use the best of OOD just a few) will eventually fail when Wicket application will continue to grow being controlled.
- With Wicket you have control over all HTTP protocol. Say you can manage how long page should be cached. You can decide what you render as the response - redirect to the page or the page itself.
- You don't need Seam conversations or pageflows with Wicket. You can organize pages in whatever manner. You can know what page was redirecting to this page and let the user return back. You don't have to split exception handling to request processing time and rendering time so you can easily employ Open Session in View technique. You don't need to map your data to contexts. You just put your data to Component, Page or Session. If you have conversation create a Java class for it. When you don't need it anymore the data will be garbage collected.
- You have a great support from IDE when refactoring code since it is more java than XML. Generating constants for component ids is planning for Wicket 1.5. So you will have full refactoring support.
- Wicket provides you with well-thought exception handling. You never loos the exception. You never loss messages between requests.
- It is easy to debug Wicket applications. You have ajax control panel on the page and several debugging and tracing options. Your contexts are always at hands so you can use all your java debugger capabilities.
- You really can write dynamically rendered components and pages. Wicket-RAD is the example. You just put property grid or object-list panels onto your page and that's it.
- Wicket has such a great mechanism as behaviors. You can design your functionality as a behavior and add it to the component instead of subclassing it. So you can build your components from re-usable parts. Wicket ajax engine is mostly built as behaviours so you can add ajax capabilities for your custom components with ease. But this skill requires deep understanding of Wicket :)
- Many cases where I used workaround for JSF, Richfaces or Seam degraded to one line of code for Wicket. It seems that Wicket is done by people who know how to design frameworks :)
The disadvantages are the following:
- Lack of well-tested reusable components, especially layout components. You can employ jQuery plugins or use one of the wicket stuff projects.
- Lack of native IDE support. But it is not so demanded as in case of JSF/Seam.
- Wicket don't have Excel, PDF and Mail integration as Seam provides out of the box. But fairly speaking Seam's implementation is not that I would like to see. I find it good for very simple cases. So eventually I had to switch to different integrations. From the other hand it is easy to handle the request as the resource request (for instance as download link) and when handling render XML and then convert use some OSS library to convert XML to Excel or PDF (XHTML is XML) and return the resulted file as the resource for the resource request.
My opinion is JSF and Seam are not for sophisticated applications but for application (probably consisting of many pages) that is made in very simple manner using copy-paste technique. So it is very easy to start with Seam and JSF. Wicket is for robust sophisticated applications.
Think about how your application will grow in the future and decide.
I see some trend in OSS projects. They consider Wicket or GWT. JSF is too painfull. Concerning JSF in OSS ... I have an example. I has been trying to evaluate Nuxeo EP every quarter. It fails after ten clicks. You have to logout and login again in order to continue (as usual, after exception some Seam session components are broken, Seam and incapsulation are ortogonal things). I have never seen a stable version of Nuxeo to suggest for production. The symphoms are very familiar. I saw them too much in my application. BTW Nuxeo uses sole Seam conversation for all the pages in session. It must mean something. Alfresco is stable. And it allows you to write Wicket UI for it.