Migrating to Wicket 1.4

...

Environment

• Wicket 1.4 requires at least Java 5

...

Component.getModel() and friends renamed to getDefaultModel() and friends

The biggest API break is to the getModel() method. In In Wicket 1.3 , Component had a method getModel() that returned the model object of the default model of the component. This was renamed to getDefaultModel(), as well as it's supporting methods (i.e. getDefaultModelObject() and getDefaultModelObjectAsString()). This method returns IModel<?>. This change was made as part of the 1.4-M3 release. In the M1 and M2 releases, getModel() returned IModel<T> because Component had the generic type T. In M3 and subsequent releases, only certain components (including FormComponent and all subclasses, as well as Link and several other core components) were genericized. This included defining them as ComponentName<T> and including a getModel() method that returned IModel<T>.If you are migrating from 1.3 to 1.4, simply replace getModel() calls with getDefaultModel() wherever your compiler indicates an error for this change.each component had by default a model: a Label had a model, a Link and even BookmarkablePageLink had a model property (all because they extend Component which has a model property). When we generified IModel, this had averse effects on Component: suddenly all components had to be generified and had to take the type parameter of the model that was associated with it. But that poses problems for components that use two different model types: which one should be in the lead? To illustrate the removal of the default model, take a look at the following link residing within a ListView of people:

ListView peopleListView = new ListView("people", people) {
        protected void populateItem(ListItem item) {
            item.add(new Link("editPerson", item.getModel()){
                public void onClick() {
                    Person p = (Person)getModelObject();
                    setResponsePage(new EditPersonPage(p));
                }
            });
        }
    };

You can see the type cast when we retrieve the model object from the link, just before we pass the person on to the EditPersonPage. When we migrate this code to Wicket 1.4, the example looks like this:

ListView<Person> peopleListView = new ListView<Person>("people", people) {
        protected void populateItem(ListItem<Person> item) {
            item.add(new Link<Person>("editPerson", item.getModel()){
                public void onClick() {
                    Person p = getModelObject();
                    setResponsePage(new EditPersonPage(p));
                }
            });
        }
    };

In this second example, the generics make the intent of the code much clearer: the anonymous class extending Link inside the populateItem method is now typed to take a Person as its model object, which is provided by the ListItem—conveniently specified to deliver Person objects as well. There's a price to pay: the code is more verbose and we had to specify the Person type four times to eliminate just one cast.

The Link class provides its own getModelObject implementation, which has the signature T getModelObject. In our example, it will be typed as Person getModelObject(). However, Component doens't feature a getModelObject method anymore—enabling ways for components to forgo the problems of providing type safety.

In order to make development of components easy Component provides setDefaultModel(IModel<?> model) and setDefaultModelObject(Object o) with their getter analogs. This allows Component to provide model services such as model detachment and model wrapping, while allowing users an easy way to create generified versions of model accessors by delegating to these default implementations:

class FormComponent<T> extends Component {

    public final void setModel(IModel<T> model)
    {
        setDefaultModel(model);
    }

    @SuppressWarnings("unchecked")
    public final IModel<T> getModel()
    {
        return (IModel<T>)getDefaultModel();
    }
}

FileUploadField - now requires model

...

Wicket 1.4 uses wicket.configuration instead of configuration context variable in web.xml to declare configuration type. This is done to avoid collissions with other frameworks. configuration variable is still supported, but may be removed in a future release.

Generics for most Objects

Most users - having wicket 1.3 code and migrating to 1.4 - will get many "compile warnings" due to generics.
The reason is the new typesafety. The class Component got "generified" and because all Wicket components extend Component, they require a generic too.
But for most Components that doesn't make too much sense. Therefore you should use Void as the generic.
Some Examples:

 
add(new BookmarkablePageLink("signin", LoginPage.class));

 
add(new BookmarkablePageLink<Void>("signin", LoginPage.class));

Enclosures

Prior to 1.4.2, if an enclosure was not to be rendered, it was not mandatory to add any other children to it apart from the 'child' that determines its visibility. This is no longer true as of 1.4.2: you will have to add all children, even if the enclosure is not to be rendered.

https://issues.apache.org/jira/browse/WICKET-2605

The error message will be 'org.apache.wicket.WicketRuntimeException: Could not find child with id: foo in the wicket:enclosure', even though it is not the element with id 'foo' that cannot be found. The incorrect component id display has been fixed as of 1.4.5 via https://issues.apache.org/jira/browse/WICKET-2606