If we look at 1.0/ 1.1, there are a couple things we can do better. I'd like this email to sum up a couple of things that annoyed me in the past, what were reasons for me undertaking things like the request cycle refactoring and the cleaning up of internals I've been doing here in there in the last couple of weeks.
* A found a lot of the code too implementation specific. An example of this is how the old RequestCycle worked, and how much everything was tied to Pages instead of something more generic. I understand this was done to make things easier/ hide more/ etc, and I guess we needed the first two versions to find out what would work and not. But now we have a better idea on that, defining things better, and where it makes sense use interfaces instead of abstract classes makes. I still think abstract classes are really useful in some cases, like component, but in some other case you really want to have more flexibility, and can come a long end by clearly stating the the contract with documentation. * A couple of things got really ugly when time progressed. An example of this is the old version of Page.isVersioned, which didn't just give back a boolean, but threw an exception when the page was rendering and started up a new version too. So, the name was wrong, it did more than one thing, etc. I think we should be constantly on the lookout for messy stuff like that, and if we find such code, immediately refactor it to something that is better readable and better seperated. * For the sake of simplicity, there have been creeping corner cases into Application. Such as onRuntimeException. For things users need to do very often in a application, we should provide easy/ short hand methods. Good imo are the compound models. Bad imo a method like onRuntimeException or the generic addClassAlias. And the problem with things like this is immediately obvious when you try to refactor internals. If the scoping is not right, you either have to break the API or go for a compromise. Both suck. Another good example of making things too simple and/or premature optimisation are methods like Session.getRequestCycle. Really, there is no point in having such a method, and it makes changing internals only harder. * I now agree with some users (like Ramnivas) that we took 'final' too far. Sure the whole theory behind it is fine, but we seem to be the only open source framework in the world taking things this far, and the whole world isn't crying about the other frameworks when they don't. After being religous for a while about data hiding, I partially backtracked my opinion to the point that I now think we *don't* have to make everything final/ hidden by default. We *should* pick our var/ method/ class scopes with care, but instead of the C++-ish defaulting to final, we should take into account that there might be lots of use cases for overriding we can't forsee, and user's don't allways want to wait for us bringing out a new version of Wicket. I now think it is better to use final deliberately instead of automatically, certainly for components etc. I am not prososing any concrete action right now, but just want to state how I feel about it, and that I plan to loosen up a bit in the future (like I have been doing with those request cycle refactorings). This email's primary objective is to let us try harder to be be generic instead of thinking about how to make corner cases easier, and a call to all comitters to take a critical look at how things are implemented now and improve any code you find that isn't exactly right even though it works currently. I think 1.2 will be a version we have to live with for a long time (there's a book comming out that covers that version, more and more people are starting to do real life projects with Wicket etc). So we better have all things in the right place so that we don't have to regret too much. Your sincere smart-ass, Eelco ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
