Wicket Framework Evaluation

This page provides feedback on Apache Wicket framework based upon a simple web application developed/deployed on GlassFish. The evaluation criteria is described here.

1. MVC separation - Wicket promotes MVC architecture by providing abstract wrappers over model but the actual implementation still needs to be plugged. For example, the controllers need to written from scratch anyway. There is no recommended directory structure that makes MVC inherent. This is related to the fact that Wicket is not a full-stack framework (more on this below). The framework provides a clean separation between views in HTML/CSS and business logic using POJO. However a lot (quite a lot) of glue code needs to be written to stitch them together. And it gets verbose really fast because of the multiple inner classes that keeps popping everywhere in the Java code. Also by default POJO and HTML are packaged together and mixing views/models in the same directory is very confusing.
2. DRY and CoC principles - The framework neither explicitly promote or prohibit DRY or CoC. The standard HTML/CSS/Java techniques can be used to achieve DRY. And because there is no generated code, there is no concept of CoC.
3. Ajax - The framework provides buttons/links that can make an Ajax request to the back end. But there is no explicit abstraction of XmlHTTPRequest in the framework. And so an external JavaScript library needs to pulled (Prototype in this case) for any direct Ajax invocations. The documentation on wicketstuff-prototype is kinda unclear on how the integration works.
4. ORM - Apache Wicket is a framework for creating UI applications and that's exactly what it is, nothing beyond. It is not comparable with full stack frameworks like Java EE, Rails or Grails which provides a persistence mechanism, database connectivity, full MVC support, security and other similar features. As a result, this application could not be built using only Wicket. For example, Java Persistence API (JPA) was used for database access and Prototype was used for Ajax functionality. JPA and Prototype are just the chosen ones among other multiple options available.
   1. CRUD generation: Creating a basic CRUD applications required putting together a bunch of POJOs, corresponding HTML pages, JPA controllers and stitching them together.
   2. Table creation: Defined by the chosen persistence library.
   3. Loading data in the table: Defined by the chosen persistence library.
   4. Customizing queries: Defined by the chosen persistence library.
5. Customization
   1. CSS & JavaScript: Standard HTML, CSS, and JavaScript techniques for packaging are used.
   2. Form Validation & Default Error Handling: There are validators available to enable basic checking like required, number / pattern / range / date validator. Anything above that needs to be custom built and adds to the verbose nature of the framework. For example a "FormValidator" was built to support the validation for each elements of the form. Custom messages for each validation message can be displayed as explained here. More user-friendly messages can be displayed as explained here.
   3. Templates: The template mechanism is really flexible and allows the repetitive code to be easily captured using "markup inheritance".
6. 3rd party libraries - Adding 3rd-party libraries is quite a breeze because standard HTML/CSS/JavaScript integration techniques are used.
   1. Plugins - Wicket-extensions has some components in addition to the core framework. Wicket-stuff provides components that complement the core framework. The core functionality can be extended using wicket-stuff.
      1. Date picker - There are corresponding packages available for YUI, e.g. "org.apache.wicket.extensions.yui.calendar" for adding DatePicker widget.
      2. Pagination - Pagination was quite simple to implement.
7. IDEs - NetBeans provides the most advanced support for Wicket development. But the recommended way is to start with a Maven project and NetBeans provide good support for that as well. More on IDE support here. The Edit/Save/Deploy/Refresh cycle required by the Jetty is time consuming though.
8. Browser compatibility (Firefox, Safari, IE) - The app was tested on Firefox 3.5.2 (on Mac), Safari 4.0.3 (on Mac) and IE 7.0.600.118000 (on Windows Vista) and no issues were encountered.
9. Production deployment - Generating a production deployment on GlassFish is very straight forward because of Maven, just create a WAR file using "mvn package" and deploy directly.
10. Maintainability: The framework requires a good grasp of Object Oriented concepts like inheritance, encapsulation and inner classes. Even though these concepts are very powerful but they can be a maintenance nightmare. Also, the verbose nature of framework will likely make it cumbersome as a maintenance effort. However there is no real experience or feedback in this area.
11. Any outstanding feature ?: The response time on the Wicket user list is truly outstanding. Most of my issues encountered during the development phase were resolved by asking questions there.
12. Any pain point ?: As with any new framework, there is always a learning curve. The framework has a large set of APIs and so it takes a while to figure how the pieces fit together and can be assembled together to create a solution. If you are developing with Wicket, then the official documentation is pretty minimal and not much helpful. The very first link in the documentation actually points to Books on Wicket which is indeed a key resource. I borrowed "Wicket in Action" book from a colleague and it turned out to be helpful. But unfortunately the API has evolved since the book was released and so some of the recommendations from the book are already deprecated. The Wicket user list is definitely a very responsive resource and help me build a better understanding of the framework. Wicket Stuff provides a good set of examples as well with complete source code. But even here some of the samples are using deprecated APIs. Another pain point is that "search engine-driven development" paradigm cannot be applied easily because the search results are a mix from the pre- and post-Apache versions of blogs/docs/etc.