Posts Tagged ‘web applications’
Several months ago, I was assigned the task of developing a web application for a Fortune 500 company. The specific purpose of the application was to allow certain transportation providers to submit claims directly, something they had previously been doing though e-mail. Once submitted, a provider would then be notified with regards to status changes in their claim as it made its way through the company’s revenue system. A provider could then re-log back into the web application to review the particulars of that change.
What made the assignment notable from others was the fact this company had recently set architectural guidelines restricting new web application development to use only the Wicket framework. As some of you already know, Wicket is component based framework competing in the same space as JavaServer Faces (JSF) and Tapestry. Having never worked with Tapestry before, I did have prior experience with JSF. I had been on two previous projects using Apache’s MyFaces, and by the end of my second project, I had some real reservations about recommending JSF as a web application framework. If I had to sum it up at the time, JSF just seemed inconsistent when predicting how you would think it would behave. There were occasions where if you did two similar things in different parts of your application, they wouldn’t necessarily behave similarly. One would be slightly off kilter, requiring you to make tweaks to your code that weren’t required in the other spot to get the same sort of operation. I’ll be first to admit, this might have been in large part due to the third-party JSF components that were purchased for the latter project. So it was with some apprehension that I started this project with yet another component based framework.
Now that I’m near the completion of that project, I’m happy to say that Wicket as a component based framework pretty much flat out works. It may not be perfect, and I believe there aren’t any, but compared to some other offerings, it works. So I thought I share a few top level concepts that I think are core to evaluating and understanding this framework.
But before I begin, learning a component based framework can be daunting, especially if your background is only one of the classical request-response frameworks, like Struts or Spring MVC. It can represent a significant paradigm shift in how you solve the problems at hand. So to help you in that process, I recommend reading the Manning’s publication ‘Wicket in Action’. It’s authored by two of the framework’s committers, so without doubt you can consider them to be experts on the subject. The material they present is done in such a manner so as to keep building on previous concepts, such that you never have the feeling you missed a turn somewhere. By the end of the book you should have a reasonably good understanding of the framework to tackle a moderately complex web application, assuming of course you have previous experience. I say moderately complex, because the book won’t explain how to use some of the more advanced Wicket components, like data grids and accordions that so many web applications are now expected to have. That unfortunately, you’ll have to do that on your own – but hey, you gotta start somewhere.
Now on to some key observations. When learning Wicket, the first thing you’re going to have to understand is models. Without understanding models, you’re never going to get anywhere. Models are the glue between the components and the objects containing the information your app is expected to use. Simply put, they are placeholders that you share with the component. It allows you, the developer, to even change the data object with a different instance while keeping the component completely oblivious. Wicket has several different models, but of all of them, knowing when to use the LoadableDetachableModel is important. Here’s why.
One of Wicket’s key features is its solution to one of the ‘Holy Grails’ of web applications – built-in support for the back button. It does so by serializing each and every page, which basically means the components and the models they reference, to a Wicket abstraction called a PageMap. PageMaps themselves can be written to disk, so as to limit the amount of HTTP session being used. When you hit the back button all that you’re really doing is restoring that page’s state as previously captured in the PageMap. Sounds expensive, but it’s not nearly as bad as it could be if you are using a LoadableDetachableModel. What a LoadableDetachableModel will allow you to do is control what gets serialized. So what if your model references an entity, which is typically a row in a database. Then it makes sense that all you would want to do is serialize the primary key. Why? Well like most component based frameworks, Wicket has several distinct phases it goes through with each request – response cycle. At the end of a response, Wicket will call the detach method on all components using a LoadableDetachableModel. This will set your entity object in the model to null before things get serialized. Then at the start of the next request, when the component requests the entity, it will get restored. How? Well the LoadableDetachableModel sees that the entity is still null, so it calls a method that you supplied called ‘load’. Of course by now the primary key you had previously stored is already deserialized. All you have to do is get the entity back from the database before Wicket does anything to it, like binding new values posted from the browser. Pretty slick!
All web applications are expected to do Ajax these days, and Wicket does not disappoint. It has a well integrated Ajax framework that’s easy to use and easy to control. It’s as simple as using an ‘Ajaxified’ component, or adding an Ajax behavior to a component that isn’t to initiate an Ajax request. Then all you have to do is decide what components should be updated as a result of receiving the request. Let me give an example. In the web app I built for my client, there was need to allow the user to search for current and previous claims. The business owners wanted to supply two distinct methods of searching, by allowing the user to either fill out one set of fields and search, or fill out the other set and search. To make the user interface less confusing, I decided to use a dropdown with a simple description of each of the search methods. I also encapsulated the fields associated with each of the searches into a Panel. A Panel is nothing more than a component that can act as a container for other components. But more important is that you can also associate with the panel its own html fragment for displaying what’s in it, the search fields in this case. And a Panel can also provide the necessary validation and business logic that may be required for those fields. This really makes it nice when you want to reuse them throughout your application. But here’s how the rest of the design unfolds.
I used a DropDownChoice component, and as you can probably already guess, it was used to represent my dropdown. Because this component isn’t inherently ‘Ajaxified’, some are and some aren’t, I had to add an AaxFormComponentUpdatingBehavior to instruct the component to make an Ajax request with each ‘onchange’ event of the dropdown. Behaviors, like models, is something else you will need to know. They are often used to add new capabilities to a component – like Ajax. Anyway when the search page is initially displayed, only one search panel is shown. When the user doesn’t want that one, he makes a new selection in the dropdown. This creates an Ajax request where it will be received back at the behavior’s handler on the server. All I had to do at this point inside the handler was determine the new state of the dropdown, select the appropriate panel to be shown, and tell Wicket to render this one and not the other. When it was all said and done, the panel swapping amounted to just a few lines of code. All of the nitty-gritty update details and Ajax plumbing was handled by the framework. Sweet!!
I have just one last thing I’d like to mention about Wicket, and that’s its excellent templating and page layout features. What makes Wicket different is how you associate your page’s HTML with the java code. It’s through the class hierarchy. So wherever you create a class to be used as the code for the page, you also create an HTML file in the same package with the same class name, but instead with a ‘html’ file extension. So whenever your class gets instantiated by the framework, it also knows if there is an html file with same class name, then this is the HTML to be used.
Big deal, right? Well read on a little further. What the Wicket folks have cleverly done is not only load the html with this class, but any html associated with any of the classes up the hierarchy, basically allowing you to nest the html that is lower in the hierarchy into the html that is higher. All through the use of the Wicket tags <wicket:extend> and <wicket:child>. So how do you use this to your advantage?
Well like working with other web frameworks, you generally create a base class that serves as an extension point for the rest of your classes, and with Wicket WebPage it is no different. But what you’ll want to do with this base class is also create an html file with the same name that defines the overall look and feel of your web pages. It may display the application’s title at the top, maybe a place to put menus to the left, etc. This page will basically act as your application’s template. Any class that extends this base class and provides its own html can place it inside of this template. Cool! Gone are the days of all those nasty Tiles’ definitions. As a matter of fact, throughout the entire development of my app did I ever once have to create a single XML file for Wicket! I just followed the conventions and things worked.
If your thinking about venturing into the realm of component based frameworks and you have been searching around, please give Wicket some serious consideration. It may not be easy at first, but I think once you get over the hump you’ll learn to appreciate what it can do for you.
By: Mark Raterman