On Tue, Jan 10, 2012 at 12:21 PM, Emond Papegaaij <[email protected]> wrote: > 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.
+1 Objections? Other ideas ? > > 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
