Hi, everybody. I'd like to take a moment to introduce myself, as I am
interested in contributing to the Wicket codebase.
Around 2005 I became dissatisfied with the (then new) JavaServer Faces
(JSF) framework promoted by Sun. I liked their idea of having a
component hierarchy on the back-end, but I didn't think they took that
concept far enough. I had an extremely deep background in Swing, so I
decided to create my own web application framework from the ground up,
naming it "Guise". I used the Guise Framework
<http://www.guiseframework.com/doc/intro/> for a single commercial
project for a client, but for the past few years I've been doing more
desktop work with Swing again and haven't had time to take it any
further, although it continues to run all my personal sites including
the link above.
In 2010 I started working for another client, who was primarily using
Wicket on their site. I had never heard of Wicket before, but as I went
through the code I had a sense of deja vu, as so much of the
architecture is similar between Guise and Wicket, and I saw many similar
implementation dilemmas each framework had to address. Both Guise and
Wicket start with the concept of an application framework with a
server-side hierarchy of components, with all event processing handled
on the client. There are a few differences, though:
* Wicket requires the developer to create an HTML skeleton upon which
components are injected. Guise automatically generates 100% of the HTML
at runtime from the server components (with pluggable renderers, similar
to Swing). Developers write no HTML or JavaScript; for all they know,
they could be writing in a variant of Swing with generics.
* Wicket allows some Ajax capability, but in Guise Ajax functionality is
baked in. Everything works off Ajax. As we didn't have things like
JQuery and such back in 2005, I had to write all the XMLHttpRequest
processing myself. (And please don't even mention the nightmare that was
IE6!)
* Wicket encourages subclassing to handle events. Guise instead uses a
system of even listeners (again similar to Swing).
I've been very impressed with the architecture of Wicket. In particular
its system of models is very elegant, allowing detaching and reloading.
Its handling of persistence between HTTP requests and multiple open tabs
is far ahead of Guise, which keeps a single entire component tree in
memory and assumes there is only one "view" at one time per session.
There are so many ways I'd like to improve Guise based upon my
experience over the years, but I don't have the free time. And I can't
recommend Guise to my clients, because there exists no community to
support it. However it turns out that my current client has just started
using Wicket. I'll like to contribute back some code to Wicket to make
it even better, and perhaps some of my experience from my Guise project
can be beneficial. Maybe someday I'll get to use my Wicket experience to
go back and make Guise everything I wanted it to be. Or maybe Guise
could be a module of Wicket---who knows.
For now I'd like to offer some feedback and make some suggestions based
upon our needs on my current project, and once the current Wicket team
feels comfortable with my competence perhaps I can make some code
contributions as well. In particular I note that one of Wicket's main
goals is to eliminate boilerplate, but some of the same shortcomings I
saw four years ago seem to still be around, requiring a bit more
boilerplate (and scouring the web for examples) than may be necessary.
I'll offer some proposals in separate emails.
I look forward to working everyone and making Wicket even better and
easier to use.
Sincerely,
Garret Wilson
- self-introduction, Wicket development Garret Wilson
-
