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[2]).
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 !
