Summary
Julian Sinai has worked on a Wicket-based project for the past year, and summarizes his experience with the framework in a recent blog post.
Advertisement
Apache Wicket is a relatively new Web development framework. According to its creators, Wicket's main goal is to provide a Web programming model familiar to Java developers, separate the presentation and business logic concerns, and define an easy-to-use mechanism for state management. The result, according to the Wicket developers, is an effective Web development environment:
In terms of efficiency versus productivity, perhaps Wicket is to JSP as Java is to C. You can accomplish anything in Wicket in JSP. You may even do it more efficiently in terms of memory or processor consumption. But it may take you weeks or months longer to develop your application. And in the end, since state management in JSP is ad-hoc, you are likely find security problems and bugs popping up everywhere. Most of the other frameworks above will do only a little more to help you.
One of the benefits of Wicket is that developers with a Swing background find Wicket a familiar environment. Julian Sinai is one such developer, and he had a chance to work for a full year on a Wicket project, summarizing the experience in A Year of Wicket:
Because of my Java and Swing background, I was drawn to Wicket. It maps fairly closely to the Swing model of development. So does GWT, but when I evaluated it, it seemed so different from other J2EE frameworks that I felt it was a step too far. No HTML, and no WAR files, for example. This made my colleagues nervous, who were used to Struts and PHP. Me too, as a matter of fact.
Sinai notes that Wicket allowed him to get started on the project quickly:
Right out of the gate I was able to create a framework with Wicket 1.2.6 that my colleagues could fill out, consisting of a navigation tree, a base page, database-driven tables, graphic buttons, page headers, tabbed panels, and a CSS-based look and feel.
Wicket's separation of concerns is also an advantage Sinai found useful in his project:
One of Wicket's advantages is the strict separation of design from behavior, that is, HTML from code. While we did not have a web designer on the team who built the HTML (the developers did this), and therefore didn't get any mileage from the separation in that sense, we definitely gained from having all the behavior in Java code, because it gave us all the power of refactoring, compile-time error checking, and maximum reusability...
We made sure there was no cut-and-paste reuse, and instead if a component did not have a necessary feature, I spent the time to add that feature. This paid off in spades later in the project, since if a bug was found or the look and feel needed tweaking, it typically only needed a change in one place. The number of bugs related to errors in the Wicket code was tiny. All the bugs were about the business behavior, that is, misunderstandings between product management and engineering, which is where you want any bugs to be.
Sinai's team also found Wicket's support for Ajax applications helpful, but not without some problems:
We decided the time had come to convert as much of our interface to use Ajax as possible in order to make the user experience more interactive and up to date. This is where Wicket really shone, but was also where we ran into some difficulties. It was surprisingly easy to Ajaxify the paging tables and to create lazy loading panels (panels that fill themselves lazily in when loading a page), a little less so to Ajaxify tabbed panels, and not easy to figure out how to create an Ajax button that pops up a confirmation (yes/no) dialog before proceeding with the submit action. The latter is because for someone like myself, who is much more at home with Java than Javascript, finding out how to do anything out of the ordinary with Wicket and Ajax is painful. This is one area where the docs and examples can be improved, particularly with so many applications going Ajax. In the end, though, we were very pleased with how little code change it required to the application as a whole.
What's your experience with Wicket? Where would you place Wicket in the spectrum of Java Web frameworks in terms of ease-of-use and productivity?
I have used several web application framework before, wicket really hit the nail I think. It is easy to use in legacy application to improve, rather than I need to rewrite a lot of thing. It suggest clean component oriented design, meanwhile I can easy put HTML generated from legacy library to my new function.
Where to place Wicket: The main reason that I got involved was because I was looking for a framework that scales well for development. Whereas most frameworks seem to focus on short-term gains (build something quick now), Wicket is focussed on an extensible programming model that will let you take full advantage of Java and it's tool sets. And this helps enormously in creating maintainable apps (refactoring and code-reuse are a breeze for instance) and distributing work (the ability to work on fine grained components without being in each other's way, and using web designers on the project is very doable).
What people don't always like is that working with Wicket can at times be verbose compared to other frameworks. There are good reasons for Wicket working like it works (like a clean separation of concerns), but it is hard to argue on taste :-) The good thing is though, that since it is easy to create custom components, it is easy to create an API to your liking. The post points that out nicely when they talk about how they created a custom form. Another nice example of this is Al's: http://talks.londonwicket.org/BeanEditor.mov.
I've been working with Wicket to build a small prototype app. Here's my assessment so far:
First the bad - the documentation is thin. The examples are the best place to start but unfortunately, the examples are not stand-alone. You can't just take one of the examples, plop it in your container and start hacking. You have to go out and gather the required parts that are inherited from the base classes. This is not a big deal once you get the feel for Wicket, but when you are completely new to it, it's very frustrating.
It can sometimes be difficult to match up the hierarchy of the tags in your HTML with your code. I think there may be tools that help with this, but otherwise you have to build the trees in your head and compare them in your imagination.
Now the good - despite the poor documentation, Wicket is pretty easy to learn once you get a basic idea of how it works. There are some tutorials that help a lot. One of the big things that is good is a that there is a consistency of approach across components. For example, you can build the rows of a table with a Repeater. You can also build the column headings with a Repeater.
The biggest benefit I see from Wicket is that changes are fairly easy to implement. As my prototype application gets more and more features, I don't find myself having to redesign things from the ground up. Changes are mostly confined to a single place in code. Often the web interface can be altered without any code change at all.
The hardest thing for me is trying to sell Wicket. We are only supposed to use 'standard' solutions. Becoming an apache project helps a lot but even then the lack of documentation makes it look immature. Honestly, I have a hard time coming up with a good argument for adopting a framework with little more than a thin wiki and JavaDocs for documentation. I hear a book is in the works and that may be enough to make a case.
Personally, I think Wicket's lack of structured on-line documentation is made good by the examples (94!) in the wicket-examples project, and all the examples you can digest from looking at the 3rd party projects such as the ones you can find in Wicket-stuff. I also think we do a decent job with Javadocs, and if you look at the WIKI (which is for 80% maintained by users) and list archives, you can find answers on just about anything Wicket related.
Enjoying web development with Wicket (http://www.agileskills2.org/EWDW/index.html) is from the same author as the successful Enjoying web development with Tapestry, and the first few chapters can be downloaded for free.
And we (Martijn Dashorst and I) just finished writing Wicket In Action (http://www.manning.com/dashorst/), but part of that book also has been available for months via early access. You can download the first chapter for free.
> Thanks James, glad you liked working with Wicket. > > Personally, I think Wicket's lack of structured on-line > documentation is made good by the examples (94!) in the > wicket-examples project,
Well in addition to the problem of the examples not being standalone that I mentioned above, they only really help you if you want to do something exactly like the example. I wanted to make a ajax editable grid and had a really hard time figuring out how to make the fields a dynamically specified size that didn't change when in edit mode. I eventually gave up. I was never sure whether it could be done or not. Good documentation should give you a good idea not only of capabilities and also of limitations.
And back to the examples, I really think that there should be some getting started examples that don't have dependencies on anything else other than wicket. It should not depend on a parent page. I know that this isn't the best way to structure a web application but the point of getting started example is not mastering web app design.
> and all the examples you can > digest from looking at the 3rd party projects such as the > ones you can find in Wicket-stuff. I also think we do a > decent job with Javadocs,
The JavaDocs are great (maybe even nearly perfect) and indispensable but don't help in understanding how everything fits together.
> and if you look at the WIKI > (which is for 80% maintained by users) and list archives, > you can find answers on just about anything Wicket > related.
I all for Wikis but they just look like crap to pointy-haired-bosses. The reality is also that most wikis are largely incomplete. When I go out and find a link to an unwritten section, what should I do as a newbie? All I know is that there's something to be known about that subject but I'm on my own to determine what it is.
> Well in addition to the problem of the examples not being standalone that I mentioned above
That's a fair point. The pages in the example extend from a base page to implement a consistent look and feel. Though I never thought it would be difficult for people to figure out, it is a distraction from the example at hand. I'll discuss this.
> The JavaDocs are great (maybe even nearly perfect) and indispensable but don't help in understanding how everything fits together.
I agree, and that's why I spent more than two years a large share of my spare time writing Wicket In Action.
> I wanted to make a ajax editable grid and had a really hard time figuring out how to make the fields a dynamically specified size that didn't change when in edit mode.
It is fairly simple to do. Create a grid (e.g. datatable), add a form and editable labels. The size thing can be solved in various ways. The thing is that we can't write documentation for every conceivable combination of components. Even 4,000 pages wouldn't cover that. Wicket provides a basic set of tools (components, models, attribute modifiers) and you combine those to create your own stuff. Use your brains, and when you get stuck, ask on the mailing list (some examples were actually created to answer questions on the mailing list) or on IRC (##wicket at irc.freenode.net, 60 people online last time I checked). And when you have a particular problem solved, you are more than welcome to contribute to the WIKI.
> they just look like crap to pointy-haired-bosses
Your boss should care about money and schedules and stuff. Tell him - amongst other things - about the amount of money he could save by picking a framework that scales well for development and that produces maintainable code. If your boss gets upset by WIKIs, consider sending him to a management school. :-)
> > they just look like crap to pointy-haired-bosses > > Your boss should care about money and schedules and stuff. > Tell him - amongst other things - about the amount of > money he could save by picking a framework that scales > well for development and that produces maintainable code. > If your boss gets upset by WIKIs, consider sending him to > a management school. :-)
Right now the argument against wicket is that we should use something that 'any' Java developer we find will already know. My argument is that even if that were the case for the other 'well-known' frameworks (which it isn't) it makes no sense to use something that is guaranteed to cost more in terms of development time and absorb an up-front cost for a theoretical benefit. It seems to me that it's better to keep things simple because any Java developer will but up to speed in a short amount of time even if they've never used it.
Makes sense to me but I think the real problem is that no one else feels comfortable with something that isn't blessed by a big vendor.
I'm certainly not endorsing Wicket as a project - but something about this argument doesn't sound right.
Keeping things simple == less code reuse == more bugs == more code to maintain.
That's what simple means to me in this context at least, unless of course you have another framework approach in mind that is both well known to any java developer AND doesn't do the above.
I think the idea of re-usable components is a pretty solid programming concept. If you need developers that aren't required to be able to learn those kinds of concepts maybe some point and click GUI builders will be a more attractive route to go. (obvious sarcasm)
> Right now the argument against wicket is that we should > use something that 'any' Java developer we find will > already know. My argument is that even if that were the > case for the other 'well-known' frameworks (which it > isn't) it makes no sense to use something that is > guaranteed to cost more in terms of development time and > absorb an up-front cost for a theoretical benefit. It > seems to me that it's better to keep things simple because > any Java developer will but up to speed in a short amount > of time even if they've never used it.
> Right now the argument against wicket is that we should use something that 'any' Java developer we find will already know
Hah, but that's actually one of Wicket's biggest pros: it's plain Java (and HTML) programming model. You don't need to learn/ buy new tools or learn DSLs, just the API. :-)
> it makes no sense to use something that is guaranteed to cost more in terms of development time and absorb an up-front cost for a theoretical benefit
> the real problem is that no one else feels comfortable with something that isn't blessed by a big vendor
I for one never cared about such things. I've always been able to fend off the force feeding of EJB 1/2 for the organizations I worked for, and I've used countless obscure projects in the past with great success. In fact, I think we can look back the last decade and conclude that many of the technologies pushed by big vendors turned out to be nothing more than money and productivity traps.
> In fact, I think we can look back the last decade and conclude that many of the technologies pushed by big vendors turned out to be nothing more than money and productivity traps.
Well stated. What ever happend to simple, functional components? The industry is and has been steam rolled by "marketechture"!
> I'm certainly not endorsing Wicket as a project - but > something about this argument doesn't sound right. > > Keeping things simple == less code reuse == more bugs == > more code to maintain.
I'd say it's more like:
keeping things simple == less code == less bugs == less code to maintain.
I think you are thinking of 'simple' as 'dumb' (as in 'simple minded'). What I mean is 'simple' as in the opposite of 'complex'.
More specifically, I mean unnecessary complexity. Development in Wicket eliminates a lot of the unnecessary complexity in the more well-known platforms like Struts.
And lest anyone is confused, complexity doesn't mean smart. In my experience, the best developers find simple solutions to problems. Many terrible developers come up with extremely complex solutions for the same problem.
> I think the idea of re-usable components is a pretty solid > programming concept. If you need developers that aren't > required to be able to learn those kinds of concepts maybe > some point and click GUI builders will be a more > attractive route to go. (obvious sarcasm)
That would be keeping things dumb and not what I am talking about.
> I for one never cared about such things. I've always been > able to fend off the force feeding of EJB 1/2 for the > organizations I worked for, and I've used countless > obscure projects in the past with great success. In fact, > I think we can look back the last decade and conclude that > many of the technologies pushed by big vendors turned out > to be nothing more than money and productivity traps.
In fact EJB is the exact counter-example I've latched onto in my arguments for Wicket. I heard this same argument about how we needed to do EJB because we could be developers 'off-the-street' to support it. Then the whole thing imploded and less and less developers work with EJB.
That's why I call the benefit of 'doing what the masses know' theoretical. In a few years everyone's going to be using Wicket ;-) and we'll be trapped in Struts or JSF or some crap.
>> Well in addition to the problem of the examples not > being standalone that I mentioned above > > That's a fair point. The pages in the example extend from > a base page to implement a consistent look and feel. > Though I never thought it would be difficult for people to > figure out, it is a distraction from the example at hand. > I'll discuss this.
When I first studied the Wicket examples, I was thwarted by all the "magic" being done by base classes that I didn't understand. Later, they provided me with a good example of abstracting out common elements from a series of web pages. Plus, once I understood the framework for the examples, learning new widgets became easier -- I could get right to the point without wading through lots of boilerplate code.
So I think maybe you should have a _small_ set of simple, self-contained examples with common boilerplate, then show the same examples using your example framework that removes the boilerplate code, and then continue using that framework for the rest of the examples.
Previous Topic
