Wicket

I've been thinking about Geebis Books and the philosophies that we have and I've decided to reevaluate our choice of web frameworks. We chose Seam because it looked like it was a decent framework that was built on mature technologies. After spending time with the framework we learned that our initial thoughts on Seam were true. It's built on a pile of Sun standards. Sun standards aren't all bad. Wicket for example uses a servlet to do it's work, but using a bunch of standards based products does have some downfalls. It can be slower to react to new technologies and often has other issues like being burried in a sea of xml config files.

And that's why I've decided to look at the Wicket web framework instead. While Seam has a lot of features, and I won't have too hard a time finding a job related to Seam/JSF, it just doesn't seem like it fits with the Geebis culture. The biggest reason is that creating custom components in JSF can be difficult, especially if you want your components to have lots of javascript/css that it contributes to the page. JSF requires that you use a writer to send your component's HTML to the browser. With this system you end up with spaghetti code that's hard to debug, and hard to test. Add ajax functionality to the mix and you have a featureset that JSF just can't handle in the current version.

I know about Facelets, and I know about all the Ajax frameworks out there for JSF, but those things do not reduce the complexity to the point where I would feel comfortable pumping out thirty controls.

I've read more than a few flamewars on Javalobby about JSF vs Wicket vs <insert framework here>. The JSF supporters have a good defense for a lot of the attacks, but when someone comments on how difficult it is to create custom controls in JSF, they say that you shouldn't be creating too many controls if you use the framework correctly. Creating custom controls in a component web framework id definitely what you do. That's why we use these things and not Struts. Plus, if it weren't something you should be doing, then why does Oracle and so many other vendors have large collections of components that you can buy or download?

That's the JSF part of Seam. The Seam part of Seam is actually pretty cool, and I wish I could use those parts, but I don't think they're shiny enough to put up with JSF. Dependency injection, outjection, conversations and workspaces are all very cool. I didn't get too far into using those features, but they looked very much of the now.

Aside from Seam, I've also decided to look at using an embedded Jetty webserver instead of JBoss. Because GB is meant to run on an internal network with a small number of clients connecting to it we can't justify the download size, complexity, or memory consumption of JBoss for Geebis Books. This decision means that we have to sacrifice some enterprisey features, but I think in the end it's the right thing.

On to the Wicket parts of the post.

I chose to look at Wicket as the replacement web framework because I had seen it in the past and liked what I saw. Wicket is a framework that includes everything you need to develop modern web applications:

• A templating system for creating consistent a consistent look and feel for your application


• An ajax system for making your application repsonsive


• Localization for those pesky strings


• A security framework that is customizable

Those are all features that you would expect to find in a modern web development framework, but what's interesting about Wicket is how it does those things. A quick way to describe Wicket would be to say that it is Swing for the web. Everything is done with events and callbacks. When you add a link to a page if you want to do processing when that link is clicked you implement the link's onClick() callback with the functionality that you want. Want to create a new page? Create a class for that page and extend the Wicket Page class.

They way you associate HTML with a Page class also pretty cool. In the rails-esque way of defying configuration you simply create an HTML file with the same name, but a .html extension right alongside your class file in your package tree.

And of course the whole reason for looking elsewhere, creating components, is do-able in Wicket. Just create a subclass of the Panel class and put the control's html in a file with the same name as the java file. If the control needs css or javascript you can easily tell Wicket where the .css or .js files are <link>s to them will be rendered in the resulting page's <head>. If you use the same control more than once on a page, those resources will only be included once.

For more information about wicket visit the homepage or view some of the tutorial articles on javalobby.