Well, I finally had to bite the bullet and migrate a large Wicket project from 1.3 to 1.4. I was really not looking forward to it because of all the generic mess and model changes.
This was nothing against the Apache Wicket team, since they do an incredible job on the BEST Java framework ever (it is more than that.. but that is further down).
I just thought of having to review so much code and updating the ever growing set of Wicket “component” libraries, but that was the actual reason for the surge of change.
Some of the key sub projects I was leveraging were all converted (for sometime now) and were really starting to not go back to their 1.3x branches to update the older code. I saw the 1.3x branches dying. NO!!!!
I was trying to keep some of my key sub component / libraries manually synced from their newer bigger brother 1.4 code trees, but that was getting ever increasing painful and foolish. Not to mention to find bug issues fixed in the 1.4 branches, but not in the 1.3x code base I was using. So the decision was to maintain old branches for the sub projects (not my code even) or update my project and use all new 1.4 code for everything.
Jump… 1.4 1.4 is a very good great thing.
I know in the Wicket community there has been some huge Generic battles and long, long, long threads on it was the wrong approach, too verbose, too much code for no bang, blah, blah, blah. It was painful to watch since last year (thankfully they took it out of the forum and gave it a wiki home for folks to die over).
I actually find so far that 9 out of 10 times, it has made my code more understandable and actually working with models even more concise. You get the added benefit of types collisions be detected in your IDE (if you use a real one) / compile time on models in the code that you would not get until you actually put the wrong object in a model for a component… then crash and burn and do a wtf was I thinking! Nothing beats detecting issues before ever running a line of code. I have C (not ++ or #, C) flashbacks of trying to figure out what code didn’t work, but would compile. Boy I am glad I don’t code in that world anymore.
I am glad though, that I did hold out past the 1.4M3 period. Much of the early on back and forth over how to implement generics was not pretty and I could only think of moving code from M1, M2 to M3, to RC… Even sweet utility classes (albiet small classes) like ListModel and MapModel really do ease the coding and sets up the enhanced model design even better. Once again, it makes the code more understandable as to what the Model contains and what you are working on.
Of course with any cleaning, updating has spurred on some good old refactoring of my own to leverage some new efforts in 1.4 branch and even how I plan to continue to leverage Apache Cayenne in some more elegant base Model designs of my own. Should help with the whole deteaching and seperation level between Cayenne and Detachable models in Wicket so much cleaner.
So the dread, regret and final excitement was all part of my 1.4 migration. At this point all projects will of course be 1.4x and some day 1.5… (Ajax enhancements could be even more awesome to come.)
Once again, it just goes to show that Wicket never steers me wrong and increases my I love for the whole framework project (99.9% of the time) that much better. It makes Java Web development fun and exciting. Come on kids, drink the cool aid, it won’t hurt ya!
SIDENOTE:
Wicket is not just a web framework, but a Java web way of life. I don’t how many times I have told the story of that I will not / never (never say never right) go back to doing JSP development period. It is just wrong once you see the light.
Tags: Apache Wicket, Coding, development, java, Refactor, web, Web Framework, wicket
Dover
39°
Entries (RSS)