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
> > >
> > >
> >
>
