By Miroslav Kopecky on Mar 26, 2009
Yesterdays CZJUG meeting was for me really nice instead of discussion in the pub after its end, of course . One of the topics was Apache Wicket. I didn’t know about Wicket before but presentation was impressive and explanation too (done by Jiří Hradil). After this little introduction to problematic my curiosity about has increased so much that I started to read book Wicket in Action early today. Other presentation was done by very good speaker too (Vaclav Pech from JetBrains). Valcav introduced Grails in very nice light. Vaclav Pech is also one of our GeeCON Star Speaker similar to Jakub Podlesak and Lubos Petrik from Czech Republic.
Now I want to focus more on Apeche wicket. I guess presentation about Wicket could be done also by experienced Ambassadors because it's quite easy to understand. It could also improve theirs effort in even OSUM creating.
And what is Apache Wicket ? Apache Wicket is a lightweight component-based web application framework for the Java programming language conceptually similar to JavaServer Faces and Tapestry. It was originally written by Jonathan Locke and Miko Matsumura in 2004. Version 1.0 was released in June 2005. It graduated into an Apache top-level project in June 2007.
I guess it sound nice. But what does it really mean? Wicket, on the other hand, is closely patterned after stateful GUI frameworks such as Swing. Wicket applications are trees of components, which use listener delegates to react to HTTP requests against links and forms in the same way that Swing components react to mouse and keystroke events. I think the part of text where is mentioned trees of components is very important to remember.
Wicket uses plain XHTML for templating (which enforces a clear separation of presentation and business logic and allows templates to be edited with conventional WYSIWYG design tools). Each component is bound to a named element in the XHTML and becomes responsible for rendering that element in the final output. The page is simply the top-level containing component and is paired with exactly one XHTML template. Reuseable parts of pages may be abstracted into components called panels, which can then be pulled whole into pages or other panels with a special tag.
Each component is backed by its own model, which represents the state of the component. The framework does not have knowledge of how components interact with their models, which are treated as opaque objects automatically serialized and persisted between requests. More complex models, however, may be made detachable and provide hooks to arrange their own storage and restoration at the beginning and end of each request cycle. Wicket does not mandate any particular object-persistence or ORM layer, so applications often use some combination of Hibernate objects, EJB beans or POJOs as models.
I guess now it is more clear
what is going on. Let’s take a closer look at short example. I'm not inteding to create any redundancy in this case so there is the link to Geertjan's Blog. Another nice example you can find on Wikipedia too. Only my advice is to keep in your mind class Application, it very important .
Currently Go Wicket Go and NetBeans too !