Tuesday, January 17, 2006

I say Tapestry. You Say Wicket.

Tomato Tomato, Potato Potato...Well, probably not. But they aren't apples and oranges either. It seems like everytime I bring up Tapestry, someone brings up Wicket. I looked at Wicket back in its infancy; version 1.0. It looked neat and I did some very light testing with it. And then I dropped it and hadn't really looked at it since.

Since it keeps popping up in conversation I decided that tonight I would start looking at it again. I didn't see any significant changes since I used it last. The documentation has improved but it still seems the downloadable examples are still the only way to see how an entire app is really put together. I've decided that I might put my Tapestry/JSF tutorial on hold until I can possibly explain Wicket well enough to include it in the same tutorial. Kill 3 birds with 1 stone I suppose.

The hardest aspect of Wicket that I can't seem to wrap my head around yet is the use of the IModel interface and it's pluthra of implementations. The documentation does a descent job of explaining what the IModel is, but not so good and explaining when to use which and why. The examples in the documentation are about 2-3 lines long and don't mean much to me. And the framework's use of inner classes seems a bit, well, overused. Most of the time I think this is for simplicity and the ability to create less seperate files when writing how-to articles. Specifically, classes that extend Form always seem to be inner classes as well as anonymous methods for listeners. This is my favorite though.



This is code from a series of tutorials by R.J. Lorimer. This doesn't scream simple to me, especially as the site grows and becomes more and more complex. That's not to say this is at the fault of Wicket. I am betting R.J. did this for the simplicity of the tutorial, but at first glance, it's a bit confusing.

Anyway, I plan to keep chugging away for the next couple of days, possibly into the weekend when I have a chance. And then I will decide what direction my article/tutorial on these similar frameworks might be. As always, any input along the way is greatly appreciated.

5 comments:

Jonathan said...
This comment has been removed by a blog administrator.
Jonathan said...
This comment has been removed by a blog administrator.
Jonathan said...

Besides the comments on the wicket-user mailing list, you should also keep in mind that Wicket is a totally component-oriented framework. You can easily make new components that encapsulate large amounts of work. For example, this is likely to be a reality before long:

add(new ListView<Person>("people", getPeople())
{
@Override protected void populateItem(ListItem<Person> row)
{
row.add(new BeanPanel(row.getModelObject(), ...);
}
}

And you could compress that even further:

add(new BeanListView("people", getPeople(), ...);

and it would accomplish the same thing. Mainly, I think people just need to go write more powerful components now.

Gregg said...

That is basically what I wanted to see. Except I'd like to see the BeanListView class. I am assuming it would extends ListView and override the protected void populateItem method, similar to what was done on the page. This kind of coding makes more since to me.

Thanks.

zmang12 said...

Have you tried Thinwire? We use Thinwire for views that are interactive (as opposed to being view only). Its been a pleasure to work with thinwire - productivity is great (compared to any other framework out there). The widget kit is quite adequate for our needs. Give it a try - you won't ever want to muck around with JSF or Wicket or Tapestry ever again.