Presented by Martijn Dashorst, author of Wicket in Action and Vice President of the Wicket project
What is Wicket - if you ask me, Martijn, or many of the attendees of this class, it is simply the best java web framework available. More technically, it is a component oriented open source web application framework using just Java and HTML. “Writing a Wicket app is rather more like writing an event-based desktop application than a web application” - Michael Porter. How can you make use of this powerful, easy to use framework? Read more to find out.
Need help or training using Wicket? See http://www.wickettraining.com for professional training services. Team and individual training is available, as well as consulting, phone or email support, or custom coding on your project.
Wicket’s top five features (according to Martijn and the user list):
- Just Java and HTML - if you know Java and you know HTML, you can write a Wicket application. This allows designers to work better with development teams.
- No XML configuration - you can easily take this feature for granted if you have worked with Wicket for a while. If you are running away from Tapestry, you’ll notice this feature right away.
- Automatic back button support - since Wicket handles state for you, users can go back in their browser and pick up where they left off without any issues
- Object Oriented programming for the web - you can use good, object-oriented design and apply it to your web components.
- Easy custom component creation - you can easily make and use reusable components.
Just Java - components are POJO’s (just use extends). It is also an unmanaged framework, which means that you can simply use the standard Java “new” keyword to create a new page or component - you don’t have to let the framework instantiate it based on a string in an XML file.
Just HTML - we use regular old HTML - we don’t put logic into HTML, so designers can do their thing and preview components.
What is a Component in Wicket? It is a Java object that can handle events and knows how to render itself. It has an ID given to it at instantiation time (wicket:id) that matches the ID used to place it in the markup. It may or may not have data associated with it. If it does have data, this can be stored in the Model. Models are wrappers or locators for pieces of data used by components. You may think of it as a single layer of abstraction that hides where the data came from. This way the component doesn’t have to know if the data came from a POJO in session, in the database, or a URL parameter.
Use of models - Rather than sticking static data into the component at instantiation time (i.e. new Label(“mylabel”, customer.getName())), a model allows the components to always get the most up-to-date copy of the data. For instance, if you changed that label creation to new Label(“mylabel”, new PropertyModel(customer, “name”), the label now could be used on the same page as an edit form. When the form is submitted and the page is re-rendered, the label automatically shows the edited, up-to-date name.
Next, Martijn showed us a hello world example and a click counter example. The click counter example is powerful for new users wanting to see how easy it is to create custom components and see how Wicket handles state for you. I’d suggest you visit this page to see a similar example: http://wicket.apache.org/exampleajaxcounter.html
Martijn then goes into an example that will be familiar to readers of Wicket in Action - how to build a cheese store. Rather than repeating that in this post, I will refer you to the book. It is a very well-written book, and if you are thinking of doing any development with Wicket - buy a copy for everyone on the team - it’s definitely worth it!
In just twenty short minutes, Martijn was able to take HTML from a designer and create a functional cheese store with a shopping cart and checkout. This well illustrates the power of Wicket.
After this, Martijn showed the testability of Wicket by showing how to use WicketTester to create the hello world and link counter examples. Wicket makes testing individual components very easy. Rather than needing to test an entire page, you can test individual components since you have the complete ability to instantiate new components and give them real or mock models for their data access. Though I typically use whole-system testing much more (personally), this is a very important feature of Wicket, especially for teams of developers that have code coverage goals.
All in all, this was an excellent session. I was very impressed with the turnout. Thanks to Martijn for presenting it.