Wicket wicket wicket!

The folks at my current company were stuck with Struts 1.2, as was I. I never used Struts 2, so I really cannot say anything about it, but Struts 1 was great a while ago.

But, man, all that XML to add validation to your pages, complicated JSP files - either with the JSTL library or with embedded code, all those small pieces when you use tiles...

Anyway, we got this product where we had complex JSP pages and not-so-complex action pages. There was a lot of input fields but no validation - and the developer in charge decided to use JavaScript to add these validations, forgetting about the server-side of things, and we had a stream of endless problems:

. The validations started growing more and more complex - for example, the field "C" would be disabled if "A" > "B" but only if "D" = "E";
. This field is to be disabled with JavaScript, so when the user enters a value in "A", the field "C" is disabled;
. If the field "C" is disabled, then any values entered by the user have to be discarded, for that field - so the same rules that were created in JavaScript have to be added on the server.

I got really upset with that. Most times, we end up chasing our own tails in poor decisions like that, and all that trouble could be avoided by doing some research before starting. So I talked to management and I did some research on which web frameworks are being used right now - and I've found Wicket. We got the book (Wicket in Action), and I got a very simple page to build.

So, I start. I read the first chapters of the book, which are well written, and I understand the main bullet points of Wicket:

. Everything in Wicket is based in pages - you have a pair MyPage.html and MyPage.java, similar to what you would have in .Net, and far away from the concept of action classes/ JSP pages that you have in Struts;
. The "MyPage.html" is a HTML page where you add a wicket attribute (wicket:id) to each of the components that you will also add to the Java class of that page;
. One of the things I first learned is that the page class is constructed only once for each user that is accessing it - much like a desktop application. Wicket will keep the state of that page automatically and you don't need to worry about it; And, because of that, if you have a component that holds a list (like a tree or a SELECT component), and that list may change according to what the user does, you need to provide the list of items from a model and not simply send it to the constructor of the component you are creating;
. Validation is so easy it almost feel like cheating; Really. You create the text component, and then you write "component.setRequired(true)", and there you go. You can create your own custom validators, you can run your validation in the model class after the basic validation went ok.

Wicket is shipped with Ajax features. It's really easy to use - everything around Wicket can be made with no much effort. You just have to take care with your code when using lists, otherwise it can really have a lot of nesting levels.

So far, so good. I am creating a second application, bigger, and I am planning on using it from now ow.

PS: I would put code samples in here but it's Saturday morning and I have errands to run.

Interesting articles:

http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-from-spring-mvc-webflow/;
http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf