A few months ago I wrote to the Wicket user list explaining that I was
investigating view frameworks for a large enterprise project. This is a
follow up to that post explaining why I recommended Wicket. It may be useful
for other people who are going through the same decision process.
First a bit about my background. I have been building java web applications
for about 6 years. During this time I worked with custom jsp view
frameworks, struts, spring mvc, and tapestry. I spent the last two years
working very closely with Tapestry 3 (and a small amount with Tapestry 4) on
several high throughput/high availability web applications for a large dot
com. Assume for the rest of this email I am evaluating web frameworks for
large projects that will be maintained and enhanced for the foreseeable
future (choosing a view framework for a quick, small, one-off application is
a very different discussion).
---
I have read a considerable amount about the different view frameworks out
there the past few months. While each have their merits I decided to focus
on JSF (myfaces), Spring MVC, and Wicket for the purpose of doing a deeper
examination and small prototype application. That does not mean that Seam,
Rife, Trails, Tapestry, etc are not worth looking at but in my opinion the
three I choose were the best of breed for their type. I quickly determined
that myfaces was not for me. I liked its form handling and navigation
support but I did not like all the javascript and extra markup that was
inserted into every page without me asking for it.
Spring in general is a great project and I can not speak highly enough about
the products they produce. One very important contrast between Spring MVC
and other frameworks (especially Wicket) is that Spring MVC is bare bones.
It really is just a MVC framework. If you want infrastructure for ajax,
redirect after post, poups, and other common webisms you will need to build
them yourself with Spring MVC. This can be a good thing if you have unique
requirements that should be custom built in the first place but for most
projects this is not the case. Other points of consideration is long term
maintenance. A component oriented framework like Wicket encapsulates
component functionality into a black box that can be used in many different
contexts and still work as designed. The same effect is very difficult to
achieve with custom tags (especially when they have external dependencies
like javascript, etc).
The Benefits of Wicket:
1. All configuration is done in java. In my opinion this is a huge plus.
This helps development as well as long term maintenance because there is one
place to look for view logic. Frameworks like Tapestry or JSP that allow you
to place configuration in any number of places which makes it difficult to
track down the source of a bug. Using java also allows you to use
refactoring tools which can be a big boost in productivity during
development and makes it easier to verify what your changes may effect.
2. Well thought out support for common webisms (ajax, redirect after post,
etc). Instead of spending development time figuring out how you are going to
wire dwr or your own ajax framework Wicket provides a great foundation for
building ajax enabled components. The redirect after post problem is
something that every web application has to solve at one point or another
and Wicket provides 3 very good solutions out of the box.
3. Strong community with active core members. The project looks very healthy
and has a bright future ahead.
4. Powerful model abstraction. At first the Model abstraction doesn't look
very impressive but in practice it is a very powerful design pattern that
works well with the rest of the framework.
Negatives of Wicket:
1. Session support. Many other web frameworks do not use sessions out of the
box. Wicket uses the session extensively to store the render state of most
renders. This leads to a large session and if you are not careful a VERY
large session. I understand Wicket 1.3 will address this however for the
time being this is an important issue to be aware of when evaluating Wicket
( for instance the simple act of using Link to create a link that executes
java code when clicked causes the entire page and children to be stored in
the session).
2. Documentation. The Wicket code itself is very well documented but the
project could use more high level documentation describing how features work
behind the scenes. This is a common issue with open source projects however
it is particularly important for a project like Wicket to have this
documentation because it does so much work under the covers..
---
I have been involved with 3 development teams across 3 companies in the last
few months that were in the process of selecting a view framework. In each
case Wicket was considered and chosen over other frameworks. An issue each
team has struggled with is the reluctance to move away from a known
technology (JSP) to something more bleeding edge (component oriented
Wicket). Some important questions to ask the team are how much investment
has been made into custom tag libraries that can't be used with Wicket and
what is the reliance on them in the future? There are other concerns such as
ramp time and perhaps code rewrite (tag libraries that have to be rewritten
for wicket) however it is my belief that switching to Wicket will result in
increased productivity and less long term maintenance that will more than
make up for the slow start.
---
If there are any questions I will be more than happy to field them. Thanks
to the Wicket team for creating such a great project.
Ryan Crumley
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
