+1000
On Fri, Oct 18, 2013 at 9:41 AM, Carolyn Gerrard < [email protected]> wrote: > 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 >
