im all for removing the I anyways, so +1 from me -igor
On Wed, Jan 11, 2012 at 12:27 AM, Martin Grigorov <[email protected]> wrote: > 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
