Wicket (vs. Tapestry)

Wicket, as with Tapestry, is a view technology that uses plain HTML and Java code to render web sites. However where with Tapestry you have the controlling logic split between the Java code and html/page files, Wicket thrusts all logic into the Java code and use the html pages only to define the position of its components.

In addition, there is no xml configuration needed aside from the inclusion of the Wicket servlet into the web application. Any configuration is done in Java code. As such the components in Wicket can be reused and also inherit from other components, normal Java behaviour.

After trying Wicket for a few days, it is very much easier to use than Tapestry. The split logic in Tapestry forces one to constantly refer to the html pages for what components are used and their settings and the Java for the logic behaviour. Keeping all the logic in Java enables one to have a clearer picture on what the components are and what they do, and the html pages only need their wicket ids to function.

Another thing is the strict enforcement of wicket ids referencing their respective components. If one has a wicket id that is not referencing a component somewhere in the Java code, the webapp cannot render it and gives an error page. Similarly for a component that tries to add itself to a page without an id.

Shifting from Tapestry, one had to change their coding mindset from a single Java file for a html page. Wicket also requires that, however a base page can be defined and, taking advantage of inheritance, be extended by other pages. Components in one page can be reused in another and so on.