Looking at the recent discussions on the user/dev list, I agree that we should not always take the short road. I definetly like us to stick to the DRY principle: don't repeat yourself.
A good example are the 'convenience' methods we introduced in our API's: * Session.getRequestCycle() * Page.getSession() As both RequestCycle and Session are available through static methods on their own classes, there is no need for the 'easy' access methods, in fact they do more wrong than good. When creating a custom application specific component, it is easy to 'just' use Page.getSession(), while instead it would be much better to use Session.getSession() (or Session.getCurrentSession(), I don't know the API from the top of my head), as it reduces the need for a inner or nested class in the page, taking the final this pointer as a default reference. And it should be the responsibility of the concept (i.e. Session or RequestCycle) to know where it should be found, so it should be part of their interface only: DRY. I agree with Eelco that we shouldn't put final and private on everything, but I suggest we take a careful approach here: when in doubt be more strict. You can always remove private or final, but not the other way around. Or we should only ship major versions from now on ;-). Martijn ------------------------------------------------------- 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
