Working with REAL Java Objects
Tutorial - Apache Wicket: The Fun Web Framework
There is no lack of variety when choosing your Java technology stack. In attempts to get away from both the “roll your own [everything]” thinking that so many companies fall prey to, as well as the “everything must be a standard” philosophy of others, a wide range of varying approaches to each layer of the Java architecture has sprung up over the past years. The UI layer is no stranger to the struggle of competing technologies. With all of the options that you are presented with, how are you ever to choose? While no writer can make that choice for you, what we can do is introduce you to another option that you may want to consider, with the hopes that it will intrigue you enough to try it out. In this article, I'll introduce you to Apache Wicket.
As you may suspect by the article's title, Wicket is my preferred UI framework for most of the applications I write. Whether you end up sharing that same passion for this great framework – or whether it fits the type of application you desire to write – is up to you and your circumstances. But, read on and you may find another great technology to add to your “go-to” stack.
What is Wicket?
Wicket is a component-oriented Java web framework, which focuses on making it easy to write reusable code. It requires no XML configuration (aside from a few lines in your standard web.xml deployment descriptor), making it refreshing to work with. It encourages a clean separation between your logic and your markup, appealing to most programmers' desire for a sense of order. With Wicket your code is “just Java” and your markup is “just HTML”. This makes it much easier for “HTML guys” to assist with the project without fear of messing something up and without having to learn a complex templating language, parameter names and values, et cetera.
Wicket appeals to a person who loves object-oriented programming. Each component on your page is a real Java object. It can hold state and perform useful functions just like any Java object. The nice thing about this is that this state persists through web requests to abstract the complexities of the stateless hyper-text transfer protocol from you. Imagine that you have a page that has an accordion-style panel in the side navigation bar, as well as a complex data table in the main content area. A user comes to this page and expands a section of the accordion. In your code, you may call setExpandedSection(index), or you may have setExpanded(true) on it and false on the others. However it is that you model your component, you can store that user-selection as a regular Java member variable inside your accordion component or one of its children. Now, when the user clicks a link to restore your complex data table, the table itself does not need to know about the state of the accordion component – or any other component on the page. But, the accordion component, as well as all the others, automatically retain their state throughout the various other requests that the user makes.
How does it work?
To achieve the level of UI complexity described above, many methodologies require that each component on the page has some level of knowledge of the other components on the page. In these other technologies, when I click a link in one component, it needs to embed the state of the other components into its request. Perhaps this goes in the URL, or perhaps it is stored in the session. Maybe each component has a cookie prefix and stores its state in a cookie. Or, perhaps your programmers get to spend most of their time configuring interactions between components in a complex XML file that ties the inputs and outputs of various components together. Whatever the case, it's not simple programming – some of it isn't even programming at all – and it requires a constant awareness of the fact that you are writing a stateful application on a stateless protocol.
Wicket gets around this by introducing a sort-of state engine to the HTTP interactions of our web applications. When a user first visits a page, an instance of a Java class is instantiated. When constructing that class, you construct its components just like you would instantiate any other Java class, i.e. new MyComponent(“SomeID”).
When the state of those components change, they store that state within themselves as real variables with real types. After that initial page render, though, Wicket does not discard the page object that was instantiated. The entire component hierarchy is stored in the user's session (as well as disk in an efficient manner not detailed in this article). So, when they click a link to take some action on the page, submit a form, et cetera, all of that state is still contained in those classes. This is what makes it so simple (and fun!) to work with.
Now, the first thing that most people think is “won't that use a ton of memory?” The answer is no! Many people have fallen for the trap of assuming that this method is a memory-waster, but then find that this amounts to premature optimization. That's not to say that you can't kick yourself while using Wicket – you can certainly do things that will make your session size explode. We will discuss more about that below in the section “What Are Models?”. If you're really concerned about being able to validate my assertion that Wicket will not use more memory than other frameworks, you may want to check out this post and another post for a more elaborate comparison of Wicket versus several alternative frameworks (both written by Peter Thomas). If you can just trust me for now, continue on.