Wicket is the framework that I've been looking for for a long time. The
certain feature of wicket that made itself the fovorite of mine is it
doesn't allow me (and anyone from my co-programmers) to put programming
logic in the markup. A little wicket-specific tags, one wicket:id attribute
and that's it. Page authors in my team is very happy because they don't have
to learn and memorize gazillions of web framework tags anymore. All they
have to concern about is html/css/javascript and their beloved Dreamweaver.
And aside from this, they can preview the page that they are designing. And
they don't have to be bothered anymore by programmers very often.
IMO, this is the true separation of concerns between programmers and visual
designers. Programmers have concern only about java code. They don't have
to intervene frequently with the designer's markup (majority of programmers
can't do visually appealing pages, in the first place). Likewise, designers
have concern only about the html pages. They don't have to, or they hate
to, see programming logic in the html markup.
On 15/12/06, Ryan <[EMAIL PROTECTED]> wrote:
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
-------------------------------------------------------------------------
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
