So, Wicket looks very interesting, but I still have one question. Seeing as how you are obviously familiar with the most excellent WebObjects framework, what I don’t get is why do you have to configure your components in Java code? WebObjects allowed you to just do this kinda thing:

CategoryPopUp: WOPopUpList { list = anObject.aList; item = anItem; selected = theSelectedThing; }

This was before God commanded that all configuration must be in XML so the binding files were actually readable. And of course Tapestry allows you do something similar although with XML and/or annotations. IMHO, the above is more readable than the wicket style of putting all that stuff in Java code, especially when you have a big page with lots of components on it. I’ve been developing with WebObjects for 10 years and I’ve never had a problem. Of course, WebObjects Builder was nice in that you never had to actually edit this files by hand, but even before it’s introduction, this wasn’t a problem.

Thanks.

Thanks for your comments, Michael. The declaration snippet you provided looks nice and compact, much better than XML (or annotations).

In Wicket, we do think that Java is good for initializing a component hierarchy. Much of the API supports chaining, as in:

add(new RenderedLabel("text")
	.setFont(spidershank)
	.setColor(Color.GRAY));

While all of that could be declared externally in some non-programming language, many components need custom behavior that can not simply be declared. We see an advantage for Wicket here, that our components and their behavior are described in two places instead of three. When the custom behavior is needed in one page only, we just anonymously subclass its already-Java component declaration.

If you’re interested in Wicket and want to skim through example code, there’s a fair bit in the “Databinder examples”:http://databinder.net/examples.html.

Sure, in some ways it’s six of one, half a dozen of the other. The one problem I see with Wicket’s approach is that it doesn’t (easily) support the use of tools like WebObjects Builder (which you’ve got a screenshot of above) for defining components and bindings. And of course, using something like OGNL, you can embed almost anything in a binding expression that you can express in Java. However, I suppose if one wanted to add this to wicket it would take all of a day to write a few extra classes to parse something like:

text: RenderedLabel
    font=spidershank;
    color=Color.GRAY;

or

<component name="text" type="RenderedLabel>
    <font>spidershank</font>
    <color>Color.GRAY</color>
</component>

or some variation and turn it into the method calls in your code at runtime.

What I’d like to have instead of a builder is a run-time error screen (HTML+JavaScript) that lets me visually connect orphans in the component hierarchy to elements in the DOM. It would produce an updated HTML template with new or corrected wicket:id attributes, which you would then save or c&p to the right place. That’s all possible, but would obviously be a lot of work!

Wicket used OGNL in the past for interpreted component IDs but determined that it was a drag on performance. As you suggest, it would be easy to write a WebPage subclass that parses a component descriptor to build its component hierarchy. But by the time people have learned Wicket, they’re sold on the idea that doing it in Java is better. (Or they go back to learning Tapestry.)