Hi folks,
We have a large web application engineering management system deployed in
production environments that is written in Wicket. During the last couple of
weeks I have been upgrading to Wicket 6 from Wicket 1.5 in order to use the new
nested tree and table-tree components and I have to say these are really good
both in terms of the flexibility of display and performance, unlike the former
in-method grid component.
As a technology Wicket has a lot of advantages but one of the things that
constantly concerns us and our management is the amount of effort that has to
go into porting to a new release of Wicket. I'd like to ask about your
strategy for release upgrades as you need to be aware of the impact on serious
users of your product in not supporting backward compatibility of interfaces.
For example, with this port to Wicket 6 one of the changes was to the
SortableDataProvider. It went from:
private class AssignAppModulesDataProvider extends
SortableDataProvider<AppModule> {
...
@Override
public Iterator<AppModule> iterator(int start,
int count) {
...
}
@Override
public int size() {
return ... ;
}
}
to
private class AssignAppModulesDataProvider extends
SortableDataProvider<AppModule, String> {
...
@Override
public Iterator<AppModule> iterator(long start,
long count) {
...
}
@Override
public long size() {
return ... ;
}
}
As a one off change this may not seem much but we have well over a 100
different instances of SortableDataProviders in our application and
furthermore were using start and count variables in the List.subList call which
expects int . Surely a better approach would have been to introduce a new
class that supported the new interface and deprecate the SortableDataProvider
in order to prevent compilation breakage and a staged migration.
Another example is the restriction that the AjaxFallbackLink can no longer be
associated with html buttons and throws an exception at runtime if you do. We
had dozens of examples of this in code, and it was fairly painful tracking them
all down as I had to look at both java and html files to identify the ones that
came into this category.
Also the in-code rendering of js and css resources has changed completely.
Whilst I very much like the new interfaces and classes, would it not have been
possible to deprecate the existing ones at least for a release.
I understand the desire and the need to clean up the architecture of a
framework but retaining backward compatibility at least for an interim for a
mature product like Wicket really does need to be considered more carefully or
people will move away from using this technology. You don't see technologies
like Spring breaking like this.
Regards
Carolyn
