I'm +0 for the rename. I understand that IAjaxRequestHandler is a better name than AjaxRequestTarget, but it also involves quite a lot of work from our users to fix their apps. You have to remember that they have to cope with all renames at once, where you have the priviledge to deal with them one-by-one. On the other side, a rename is quite cheap in modern IDEs.
That being said, I think it should be no problem to make AjaxRequestTarget the interface, that would otherwise have been named IAjaxRequestHandler. This will give some compile errors, like where you doe AjaxRequestTarget.get(), but that's not a big deal. Those calls are far less frequent than using AjaxRequestTarget itself. Making AjaxRequestTarget an interface, would allow you to create different implement, ie for testing. Emond On Tuesday 10 January 2012 11:55:01 Martin Grigorov wrote: > On Tue, Jan 10, 2012 at 11:22 AM, Martijn Dashorst > > <[email protected]> wrote: > > -1 > > > > There is no reason other than esthetics for renaming > > AjaxRequestTarget. It is probably after Label and Link the most used > > API in our framework. This breaks all existing applications about a > > million times. > > It is not just renaming ART to ARH. > Introducing IAjaxRequestHandler actually requires changes in all > onAction() methods (onClick, onUpdate, ...). This is the bigger > change. Simple change, but I understand what you mean. > > > This is similar to renaming Form to something else, or Label to > > TextRenderingComponent. We can't just go about and willy nilly rename > > stuff because it is somewhat better. This works for minor APIs or > > relatively new APIs. But AjaxRequestTarget is as widely used as Label. > > > > For example our major 3 applications contain the following component counts: > >> find . -name "*.java" -type f -exec grep AjaxRequestTarget {} \; | > >> grep -v "import" | wc -l> > > 2671 > > > >> find . -name "*.java" -type f -exec grep " Label" {} \; | grep -v > >> "import" | wc -l> > > 6333 > > > >> find . -name "*.java" -type f -exec grep " Form" {} \; | grep -v > >> "import" | wc -l> > > 3264 > > > > That is: 2671 times a use of AjaxRequestTarget. Every and each use > > must be renamed, but even if the change is just making > > AjaxRequestTarget an interface with existing API still available, this > > warrants 2671 times a check to see if nothing breaks. > > Any advanced editor can replace any occurrence of AjaxRequestTarget > with IAjaxRequestHandler for a few seconds in a directory recursively. > Running the tests after that is a normal flow of the development process. > > > Please suggest something that doesn't break the living hell out of our > > users' code base. > > Then I suggest to remove the 'final's from the method signatures in > AjaxRequestTarget. > If this is not acceptable then I'll close the ticket as "Won't fix". > > > Martijn > > > > On Mon, Jan 9, 2012 at 3:14 PM, Martin Grigorov <[email protected]> wrote: > >> Hi, > >> > >> In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to > >> introduce IAjaxRequestHander which is an interface for > >> AjaxRequestTarget. > >> It gives the possibility to be able to provide customized ART or > >> completely new one. This way it is much easier to use a mock for > >> testing too. > >> > >> Until now we had > >> org.apache.wicket.protocol.http.WebApplication#setAjaxRequestTargetPro > >> vider() but it was useless because ART is mostly final (i.e. many > >> methods in it are final). > >> > >> The "bad" thing is that all onXyz() methods (like onEvent, onClick, > >> onUpdate, ...) need to change their signature to receive > >> IAjaxRequestHandler instead. > >> The fix is easy but depending on how much Ajax you use in your > >> application it may be a cumbersome task ... > >> > >> -- > >> Martin Grigorov > >> jWeekend > >> Training, Consulting, Development > >> http://jWeekend.com > > > > -- > > Become a Wicket expert, learn from the best: http://wicketinaction.com
