In Episode 371 of the Java Posse, Dick Wall has this to say about D.R.Y. (at 47m.30s):
"That actually, I hate to say, but it's an affliction that's very very bad in the Java world. And you see developers drop it as soon as they see another programming environment and really grok the idea of Don't Repeat Yourself. A lot of the flagship libraries in Java are really bad for this.
Wicket is one that springs to mind... everybody loves Wicket, [but] now I've been exposed to a bunch of different stuff I look at it and you have to repeat things 3, 4 or 5 times sometimes. When you're adding a field on to a Web page you've gotta name it on the page and then you come into the code and you write your handle on it with the exact same kind of component that is, and the name, and even worse, you know, taking the current Java mindset of 'you should be working for the compiler' and not the other way around.
If you get it wrong, it complains at you. It doesn't try and fix it for you."
This is, of course, exactly the problem that Metawidget is designed to address. I talk about it in my JavaOne video here (at 5m.30s).
Unfortunately work has stalled on the Wicket version while I've been working on JBoss Forge integration. Wicket actually makes completely dynamic controls, like Metawidget, tricky because of its approach of 'a Java file and a static HTML file'.
However, I was fortunate to have lunch with Wicket guru Juliano Viana at JavaOne 2011. He deep dived into the Wicket internals and found MarkupContainer.getAssociatedMarkupStream for me. It looks like this can free up the requirement of a static HTML file. So hopefully there is a way to get around this Wicket limitation.