I also did changes in Wicket jQuery UI, all seems to be ok too, I will test further the coming days...
On Tue, Jul 14, 2015 at 5:36 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > I have made the changes in Wicket Bootstrap and all seems to be fine! > > Martin Grigorov > Freelancer. Available for hire! > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Fri, Jul 10, 2015 at 10:53 AM, Sebastien <seb...@gmail.com> wrote: > > > Hi Martin, > > > > On Fri, Jul 10, 2015 at 8:35 AM, Martin Grigorov <mgrigo...@apache.org> > > wrote: > > > > > On Fri, Jul 10, 2015 at 1:27 AM, Sven Meier <s...@meiers.net> wrote: > > > > > > > Yes, an overriden method with ART parameter will be something to be > > > > migrated :/. > > > > > > > > > We can try though! > > > > > > > > I've greped the Wicket's souce code once again, and only on*()- and > > > > respond()-methods kept their ART. > > > > All other 'active' methods (e.g. ModalWindow#close()) take a > > > > IPartialPageRequestHandler now. > > > > > > > > > > I've missed that ModalWindow#close() is changed too. > > > I'll do a grep as well. > > > > > > Since this change is done for Wicket then it should be done for other > > more > > > important UI libraries like Wicket jQuery UI, Wicket Bootstrap and > > > WicketStuff Foundation. > > > I suggest to postpone the release of Wicket 7.0.0 with few weeks until > we > > > make the changes and test them for few days. > > > WDYT? > > > > > > > +1, would be a wise decision... > > > > > > > > > > > > > > > > > > If it helps, I could create a pull-request for the relevant methods > in > > > > wicket-jquery-ui. > > > > > > > > Sven > > > > > > > > > > > > > > > > On 09.07.2015 22:32, Martin Grigorov wrote: > > > > > > > >> On Thu, Jul 9, 2015 at 9:23 PM, Sven Meier <s...@meiers.net> wrote: > > > >> > > > >> Ok. you're partially right :/ > > > >>> > > > >>> The compilation error would happen if an application extends > > > ModalWindow > > > >> and overrides #close(AjaxRequestTarget) method to do some extra > > tasks. I > > > >> have such code for Wicket Bootstrap's Modal component in one of my > > > >> applications. > > > >> > > > >> > > > >> #close(AjaxRequestTarget) to #close(IPartialPageRequestHandler) > > > >>>> > > > >>> Every application has to be recompiled as the method argument type > > has > > > >>> changed. But there won't be any compilation error. > > > >>> But for a migration to Wicket 7 each application will have to be > > > >>> recompiled anyway. > > > >>> > > > >> > > > >> The problem is that we probably won't find and change all possible > > > >> candidates for this change. And once 7.0.0 is out it will be too > late. > > > We > > > >> can try though! > > > >> > > > >> > > > >> > > > >>> Sven > > > >>> > > > >>> > > > >>> > > > >>> On 09.07.2015 20:11, Sven Meier wrote: > > > >>> > > > >>> Hi Martin, > > > >>>> > > > >>>> This is what I meant as too disruptive change. If we change the > > type > > > of > > > >>>>> > > > >>>> the parameter from ART > > > >>>> > > > >>>>> to IPPRH then every application that uses ModalWindow will have > to > > > fix > > > >>>>> > > > >>>> the compilation error. > > > >>>> > > > >>>> but ART *is* an IPPRH, so there will be no compilation error. > > > >>>> > > > >>>> If we broaden the API from #close(AjaxRequestTarget) to > > > >>>> > > > >>>>> #close(IPartialPageRequestHandler) then this will be an API > break. > > > >>>>> Every application will both at compile time and runtime. > > > >>>>> > > > >>>>> Nope, see above. > > > >>>> > > > >>>> Regards > > > >>>> Sven > > > >>>> > > > >>>> On 09.07.2015 16:35, Martin Grigorov wrote: > > > >>>> > > > >>>> Hi Sven, > > > >>>>> > > > >>>>> On Thu, Jul 9, 2015 at 4:31 PM, Sven Meier <s...@meiers.net> > > wrote: > > > >>>>> > > > >>>>> Hi, > > > >>>>> > > > >>>>>> I've just changed all relevant places in Wicket from > > > AjaxRequestTarget > > > >>>>>> to > > > >>>>>> IPartialPageRequestHandler. > > > >>>>>> > > > >>>>>> I don't think this change is too disruptive: > > > >>>>>> > > > >>>>>> - client code can still call the existing methods with an ART, > > e.g. > > > >>>>> > > > >>>>> modalWindow.close(ajaxRequestTarget) > > > >>>>>> > > > >>>>>> What Maxim wanted as changes in Wicket jQuery UI are actually > > > >>>>>> changes > > > >>>>>> > > > >>>>> exactly like ModalWindow#close(). > > > >>>>> He needs to be able to close jQuery UI dialogs (non-modal window) > > > from > > > >>>>> WebSocket response. > > > >>>>> This is what I meant as too disruptive change. If we change the > > type > > > of > > > >>>>> the > > > >>>>> parameter from ART to IPPRH then every application that uses > > > >>>>> ModalWindow > > > >>>>> will have to fix the compilation error. > > > >>>>> > > > >>>>> > > > >>>>> - all places needing an ART remain unchanged, e.g. > > > >>>>> > > > >>>>>> AjaxLink#onClick(AjaxRequestTarget) > > > >>>>>> > > > >>>>>> It is not possible to click a link with WebSocket request so > > this > > > is > > > >>>>>> > > > >>>>> OK. > > > >>>>> The application developer can roll WebSocketLink if something > like > > > this > > > >>>>> is > > > >>>>> needed. > > > >>>>> > > > >>>>> > > > >>>>> - a dozen Wicket components had to be changed to cooperate with > > > >>>>> > > > >>>>>> IPartialPageRequestHandler instead of just ART: > > > >>>>>> find(IPartialPageRequestHandler.class) > > > >>>>>> > > > >>>>>> Those are good changes! > > > >>>>>> > > > >>>>> > > > >>>>> If we identify other methods later, we can still broaden their > > > >>>>> signature > > > >>>>> > > > >>>>>> to use IPartialPageRequestHandler > > > >>>>>> without breaking the API. > > > >>>>>> > > > >>>>>> No. If we broaden the API from #close(AjaxRequestTarget) to > > > >>>>> #close(IPartialPageRequestHandler) then this will be an API > break. > > > >>>>> Every application will both at compile time and runtime. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> we are very (very) close to release 7.0.0, that's why I am a > > > little > > > >>>>>> bit > > > >>>>>> > > > >>>>>> concerned > > > >>>>>>> > > > >>>>>>> So am I, but for now I think it's simpler to go one step > > further > > > >>>>>>> > > > >>>>>> instead > > > >>>>>> of 2 steps back. > > > >>>>>> > > > >>>>>> IMO, it is OK-ish to change APIs in Wicket jQuery UI > (Sebastien > > > does > > > >>>>>> > > > >>>>> this > > > >>>>> from time to time). > > > >>>>> Even if we decide to not break the API of some component then as > I > > > >>>>> suggested it should be possible to create an adapter from IPPRH > to > > > ART: > > > >>>>> > > > >>>>> MyComponent.java: > > > >>>>> > > > >>>>> add(new WebSocketBehavior() { > > > >>>>> protected void onPush(WebSocketRequestHandler handler, > > > >>>>> IWebSocketPushMessage message) > > > >>>>> { > > > >>>>> AjaxRequestTarget target = > > > >>>>> > > > >>>>> > > > > > > WebApplication.get().getAjaxRequestTargetProvider().get(handler.getPage()); > > > >>>>> > > > >>>>> modalWindow.close(target); > > > >>>>> } > > > >>>>> }); > > > >>>>> > > > >>>>> > > > >>>>> Regards > > > >>>>> > > > >>>>>> Sven > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On 09.07.2015 00:31, Sebastien wrote: > > > >>>>>> > > > >>>>>> Hi Sven, > > > >>>>>> > > > >>>>>>> > > > >>>>>>> But it seems in wicket-jquery-ui there are more methods of > > this > > > >>>>>>> kind? > > > >>>>>>> > > > >>>>>>> True, about 85 methods (taking an ART without starting with > > > >>>>>>>> > > > >>>>>>>> "on"-prefix). > > > >>>>>>> In these, I should identify the ones that should be changed > (like > > > >>>>>>> #open, > > > >>>>>>> #close, #show, #hide, #refresh, etc), the others, plus 2 calls > to > > > >>>>>>> #find(ART.class) to be taken into account... > > > >>>>>>> This is a new change since -M6 and we are very (very) close to > > > >>>>>>> release > > > >>>>>>> 7.0.0, that's why I am a little bit concerned (did I wrote > > > "worried" > > > >>>>>>> previously? ;)). I hope I/we do not miss/forget something > here... > > > >>>>>>> > > > >>>>>>> Thanks & best regards, > > > >>>>>>> Sebastien. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > --------------------------------------------------------------------- > > > >>>>>>> > > > >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > --------------------------------------------------------------------- > > > >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > >>>> For additional commands, e-mail: users-h...@wicket.apache.org > > > >>>> > > > >>>> > > > >>>> > > --------------------------------------------------------------------- > > > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > >>> For additional commands, e-mail: users-h...@wicket.apache.org > > > >>> > > > >>> > > > >>> > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > >
