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
