Hi, Thanks!
We expect such kind of feedback when we release Release Candidate versions. It is a bit late for 6.x but you can help us for Wicket 7.0. The "good" news is that 7.x won't be released soon because it has no enough breaking changes. The Migration guide<https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0> is very well documented. Much better than 1.4->1.5 and 1.5->6.0 ones, IMO, but since it has no big changes which would cause big headaches to you (our users) it won't be released until we find some. There is irony in what I'm saying but this is what I understood the last time we discussed the matter. Now to your points. See inline. On Fri, Oct 18, 2013 at 3:41 PM, 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. > This change causes compilation problems, so it should be easy for the developer to fix them, no ? Maybe your approach with duplicate interfaces is achievable but this means to duplicate all implementations of these interfaces... No one suggested it when 6.0-SNAPSHOT has been in development so we it wasn't considered. > > 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. > Runtime breaks are worse the compilation breaks, I agree. It was a bug fix actually. AjaxFallbackLink won't fallback if used with a button because <button> has no "href" attribute. We could have logged a warning instead and leave your application broken for another year or two. I'm not sure which solution is better. > > 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. > Again a change causing compilation error. I agree it is time consuming to rework it to the new way but it is easy, no ? > > 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. > I understand why you are frustrated. I had to walk the same steps for my applications. But I hope you understand that I am a mortal developer like you. The only difference between us is that I've decided to give some of my free time and knowledge to you and other Wicket users. No one forces me to do this. I do it because I like the feeling to help other people just for "Thank you". There are a lot more people (and funds) behind products like Spring. I'm very glad that you compare Wicket with Spring. This means we are doing (relatively) well! We will try to revisit the changes we made for Wicket 7 and make it even simpler where possible for all Wicket users. You are always welcome to give us a hand! The same is valid for Tetsuo and everyone else! > Regards > > Carolyn > Thank you again!
