POJO Component Model
Pages and Components in Wicket are real Java objects that support encapsulation, inheritance and events.
Ease of Development
Because Wicket is Java and HTML, you can leverage what you know about Java or your favorite HTML editor to write Wicket applications.
Separation of Concerns
Wicket does not mix markup with Java code and adds no special syntax to your markup files. The worlds of HTML and Java are parallel and associated only by Wicket ids, which are attributes in HTML and Component properties in Java. Since Wicket HTML is just HTML and Wicket Java is just Java, coders and designers can work independently to a large degree and without relying on any special tools.
Wicket is secure by default. URLs do not expose sensitive information and all component paths are session-relative. Explicit steps must be taken to share information between sessions. Furthermore URL encryption allows highly secure web sites.
Transparent, Scalable Clustering Support
All Wicket applications will work on a cluster automatically and without additional work. Once bottlenecks are understood, Wicket enables tuning of page state replication. The next version of Wicket will support client-side models for zero-state scalability.
Transparent Back Button Support
Wicket supports configurable page version management. When users submit a form or follow a link from a page they accessed with the back button in their browser, Wicket is able to revert the page object to the state it was in when the page was originally rendered. This means you can write web applications that support the back button with very little work.
Multi-tab and multi-window support
Wicket provides an easy way to write application that supports multi-window and multi-tab usage allowing developer to react properly when users open new browser window or tab
Reusable components in Wicket are particularly easy to create. Not only can you extend existing components with the Java extends keyword, but you can also create Panel components which associate a group of components as a reusable unit.
Simple, Flexible, Localizable Form Validation
It is trivial to write and use validators in Wicket. It is also quite easy to customize and localize the display and content of validation error messages.
Wicket eliminates the need to manage HttpSession attributes by hand. Page and component objects are transparently stored in the session and your application can create a custom session subclass with typesafe properties as well. All objects stored in the session can automatically participate in clustering replication.
Wicket is very extensible. Most operations are customizable through factories or factory methods.
Model objects in Wicket can be very lightweight in terms of memory and network use in a cluster. When a model is used, it can “attach”, populating itself with information from persistent storage. When the model is no longer in use, transient information can be reset, reducing the size of the object.
Wicket Border components enable the decoration of pages in a reusable fashion. This is especially useful for inheritance of common navigational structures or layout.
Support for All Basic HTML Features
Wicket supports image tags, links, forms and everything else that you’re used to using in your web application development.
Programmatic Manipulation of Attributes
Wicket Components can programmatically change any HTML tag attribute.
Once a Form validates, the model can be updated using Wicket converters. Most ordinary conversions are built-in and it is easy to write new converters.
Wicket makes image use, sharing and generation very easy. Dynamic images can be created by simply implementing a paint method.
ListViews in Wicket are extremely powerful. You can nest any kind of component in a ListView row, even other ListViews. PageableListView supports navigation links for large lists.
Out of the box tree component for navigating and selecting nodes.
HTML pages, images and resource strings can all be localized.
Wicket has numerous examples showcasing all of the above features.
If you are looking to do web application programming in Java, you have a very large number of choices these days. In fact, there are so many web application frameworks now that it has become somewhat of a joke. One blog site on the Internet poses the question: How many Java web frameworks can you name? The answer they show looks like this:
Frameworks, Frameworks Everywhere
Why “Reinvent the Wheel”?
In light of this, you may be wondering “What good is another web application framework?” Indeed. Why “re-invent the wheel?” One snappy comeback to that old saw is: because this time we could make it rounder!
But it was not simply a desire for higher quality that drove the creation of Wicket. Even with so many options, there really is no web toolkit which fills exactly the niche that Wicket fills. In fact, Wicket is quite unlike each of the frameworks above.
Wicket’s closest cousins are probably Tapestry and Echo, but even there the likeness is very shallow. Like Tapestry, Wicket uses a special HTML attribute to denote components, enabling easy editing with ordinary HTML editors. Like Echo, Wicket has a first-class component model. But Wicket applications are not like applications written in either Tapestry or Echo, because in Wicket you get the best of both worlds. You get the benefits of a first-class component model and a non-intrusive approach to HTML. In many situations, this combination may prove to be a significant development advantage.
To understand why Wicket is so different, it may help to understand the motivations that created it.
Most existing web frameworks provide weak to non-existent support in managing server-side state
This normally means lots of ad-hoc code in web applications dealing with the gory mechanics of state management. While Wicket will not allow you to stop thinking about server state, it goes a long ways towards making it easy and often transparent to manage that state.
In Wicket, all server side state is automatically managed. You will never directly use an HttpSession object or similar wrapper to store state. Instead, state is associated with components. Each server-side page component holds a nested hierarchy of stateful components, where each component’s model is, in the end, a POJO (Plain Old Java Object). Wicket maintains a map of these pages in each user’s session. One purpose of this page map (and the component hierarchy on each page) is to allow the framework to hide all details of how your components and models are accessed. You deal with simple, familiar Java objects and Wicket deals with things like URLs, session ids and GET/POST requests.
You will also find that this well-structured server state makes it very easy to deal with the dreaded “back button problem”. In fact, Wicket has a generic and robust solution which can identify and expire browser-cached pages that have become stale due to structural changes to the model of a component on the page.
Finally, Wicket has been designed to work with POJO persistence frameworks such as JDO or Hibernate. This can make database driven web applications quite easy to write.
For many applications, it will be worth trading off the increased server load of extra server-side state for decreased development costs, lower maintenance costs, quicker time-to-market and generally higher quality software. The basic observation here is that software is expensive and complex while servers from companies like E-machines and Dell are relatively dirt cheap.
In terms of efficiency versus productivity, perhaps Wicket is to JSP as Java is to C. You can accomplish anything in Wicket in JSP. You may even do it more efficiently in terms of memory or processor consumption. But it may take you weeks or months longer to develop your application. And in the end, since state management in JSP is ad-hoc, you are likely find security problems and bugs popping up everywhere. Most of the other frameworks above will do only a little more to help you.
Most existing frameworks require special HTML code
JSP is by far the worst offender, allowing the embedding of Java code directly in web pages, but to some degree almost all of the frameworks from the list (except Tapestry) above introduce some kind of special syntax to your HTML code.
Special syntax is highly undesirable because it changes the nature of HTML from the kind of pure-and-simple HTML markup that web designers are familiar with, to some kind of special HTML. This special HTML can be more difficult to preview, edit and understand.
Wicket does not introduce any special syntax to HTML. Instead, it extends HTML in a standards-compliant way via a Wicket namespace that is fully compliant with the XHTML standard. This means that you can use Macromedia Dreamweaver, Microsoft Front Page, Word, Adobe Go Live, or any other existing HTML editor to work on your web pages and Wicket components. To accomplish this, Wicket consistently uses a single id attribute in the Wicket namespace (“wicket:id”) to mark HTML tags that should receive special treatment by the toolkit. If you prefer not to render Wicket namespaced tags and attributes to your end-users, Wicket has a simple setting to strip them all out, resulting in ordinary, standards-compliant HTML.
No “special sauce” in your HTML means designers can mock up pages that you can use directly in development. Adding Java components to the HTML is as simple as setting the component name attribute. And you can then give the HTML back to your web designers knowing that they can change it with confidence.
Wicket, more than any other framework gives you a separation of concerns. Web designers can work on the HTML with very little knowledge of the application code (they cannot remove the component name tags and they cannot arbitrarily change the nesting of components, but anything else goes). Likewise, coders can work on the Java components that attach to the HTML without concerning themselves with what a given page looks like. By not stepping on each other’s toes, everyone can get more work done.
Existing frameworks are not easy
Most of the existing toolkits have poorly defined or non-existent object models. In some cases, the model is defined using special XML syntaxes. The syntaxes may be so cumbersome that special tools are required to manipulate all the configuration information. Since these toolkits are not simple Java libraries you may or may not be able to use your favorite IDE tools such as editors, debuggers and compilers.
Wicket is all about simplicity. There are no configuration files to learn in Wicket. Wicket is a simple class library with a consistent approach to component structure. In Wicket, your web applications will more closely resemble a Swing application than a JSP application. If you know Java (and especially if you know Swing), you already know a lot about Wicket.
Existing frameworks inhibit reusability
Tapestry and JSF at least have component models that allow reuse, but you are likely to find that it is not particularly trivial to do, at least when compared with Wicket. Wicket has been explicitly designed to make it very, very easy to create reusable components. It’s surprisingly simple to extend existing components and to make compound components such as a SignInPanel or AddressForm. It is also relatively easy to create components that exploit new features of browsers. Components in Wicket can be packaged up in JAR files and reused by simply dropping them in your lib folder – no configuration necessary!
Web programming should be fun!
This is my most personal goal for writing Wicket . None of the existing frameworks are appealing to me in terms of intuitiveness, quickness, ease of development, etc. It is my hope that Wicket represents a significant step in the direction of making web applications easy and fun to write.
Coming from these motivations, the following goals for Wicket emerged:
- EASY (SIMPLE / CONSISTENT / OBVIOUS)
- All code written in Java ala Swing
- Minimize “conceptual surface area”
- Avoid overuse of XML configuration files
- Fully solve back button problem
- Easy to create bookmarkable pages
- Maximum type safety and compile-time problem diagnosis
- Maximum diagnosis of run-time problems
- Minimum reliance on special tools
- Components, containers and conventions should be consistent
- Components written in Wicket should be fully reusable
- Reusable components should be easily distributed in ordinary JAR files
- HTML or other markup not polluted with programming semantics
- Only one simple tagging construct in markup
- Compatible with any ordinary HTML editor
- Easy for graphics designers to recognize and avoid framework tagging
- Easy to add tagging back to HTML if designers accidentally remove it
- Code is secure by default
- Only explicitly bookmarkable links can expose state in the page or URL
- All logic in Java with maximum type safety
- Easy to integrate with Java security
- EFFICIENT / SCALABLE
- Efficient and lightweight, but not at the expense of other goals
- Clustering through sticky sessions preferred
- Clustering via session replication is easy to accomplish and easy to tune by working with detachable models.
- The Wicket team is committed to deliver a feature complete, ready-to-use framework for developing Java web applications. The core framework was written and contributed by the author of this introduction, Jonathan Locke. The current team consists of a group of experienced programmers, some of which were active on some of the other frameworks stated above, and all of which have extensive experience building large scale Java web applications. We eat our own dogfood, and will thus work on Wicket from a framework user’s perspective.