Wicket is complicated
Posted: 22 September 2009 Filed under: java, programming | Tags: java, wicket 1 CommentI‘m beginning to think that the wicket mailing list has more traffic because they need more help.
I’m bothered that their standard idiom for the java class that backs a page does a lot of work in its constructor.
I’m finding the code examples are invariably hard to understand. For example, this is from one of the constructors from one of their sample apps. Look at the populateItem method; it receives an item parameter, which it calls getModelObject() on, then it takes the result from that and calls add() on the item parameter to add a Label. It just seems convoluted.
ListView view = new ListView("list", new PropertyModel(this, "results")) {
protected void populateItem(ListItem item) {
String result = (String) item.getModelObject();
item.add(new Label("item", result));
}
};
I still haven’t figured out how you’re supposed to handle the non-serializable objects in these page backing classes; e.g., the dao. The page backing classes are serialized and shared across instances in a clustered setup.
Sometimes in the constructor they call methods on the dao. That just seems wrong. For why, see this article by Miško Hevery.
Lumpynose 
When learning Wicket, I found it counter-intuitive that page components had to be laid out in the page constructor. There were seemingly simple things I wanted to do that seemed so difficult. For example, I have a website for internal users and I’m not picky about prettiness, and I don’t like coding HTML. So I wanted to build a library of subclassable panels and panel aggregators that I could use to assemble my pages completely in code, relying on the HTML solely from the base pages and panels. To do that, I wrote abstract base pages and utility panels which contained methods such as:
abstract Panel createPanel(String wicketIdToUseInConstruction);
to be implemented in the subclasses. Then the base class constructor could say:
somewhereInComponentHierarchy.add( createPanel(“theActualWicketId”) );
Calling overridable methods from within a constructor is considered BAD PRACTICE; it fails when the subclass’ implemented method refers to that subclass’ properties. (The overriden method is called while the base class constructor is still executing, before the subclass’ properties have been set.)
I don’t know of any good alternatives. I suppose the base class could provide a separate method NOT called by its constructor that calls the abstract method and completes the component’s construction, but then the developer would have to know to call it at the end of the subclass’ constructor. That seems contrived, and requires every subclass to define a new constructor even if it has no other work to do.