Hi,
that change seems to have a hight impact - sorry, I didn't think of
these implications.
> But #add(Component...) is part of IPartialPageRequestHandler
> so adding a component via websocket will not trigger
IListener#onBeforeRespond
WebSockerRequestHandler#addListener() was a noop previously, so we don't
lose anything here
>I guess following method need to be additionally updated:
>org.apache.wicket.ajax.AbstractAjaxTimerBehavior#onTimer
Why, an Ajax timer is triggered by Ajax calls only, isn't it?
AbstractAjaxTimerBehavior#restart() and #stop() could be invoked from a
WebSocket request though.
>All signatures have to be checked ... AjaxRequestTarget or ...
IPartialPageRequestHandler
I checked Wicket's code for methods that take ART as argument and having
a name which doesn't start with an 'on'-prefix:
There are the two methods above and ModalWindow#show() and #close() that
should be changed to IPartialPageRequestHandler. These are backwards
compatible changes actually.
There are half a dozen calls to #find(AjaxRequestTarget.class) in Wicket
classes which should switch from ART to IPartialPageRequestHandler, to
restore cooperation with WebSockets.
But it seems in wicket-jquery-ui there are more methods of this kind?
Regards
Sven
On 08.07.2015 21:30, Sebastien wrote:
Hi,
Sorry, little bit late on the topic...
On Fri, Jul 3, 2015 at 7:38 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:
HI Maxim,
This will lead to a big API break.
If we change this signature then we will have to change many more to keep
it consistent, and this will lead to a lot of work for the application
developers to change AjaxRequestTarget with IPartialPageRequestHandler.
That's exactly the point I am worrying about... All signatures have to be
checked to see whether or not it's an AjaxRequestTarget usage only or a
method that can works with websockets too (and then change the signature to
IPartialPageRequestHandler)... With the same idea,
IListener/AbstractListener are part of ART. But #add(Component...) is part
of IPartialPageRequestHandler, so adding a component via websocket will not
trigger IListener#onBeforeRespond (1) ? This would probably lead to some
unexpected behaviors, like for instance in Wicket jQuery UI where there is
a "DestroyListener" (which handles the jquery #destroy of the widget)...
Am I accurate on the analysis or did I missed a point?
Thanks & best regards,
Sebastien.
(1) actually I never double checked this is the case, but on the
principle/theoretically I guess it should be...
We may need to make this change for Wicket 8.x if there are many users
wanting this change, but for now I'd suggest you to create an adapter.
Martin Grigorov
Freelancer. Available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Jul 3, 2015 at 7:46 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:
Hello Martin,
I guess following method need to be additionally updated:
org.apache.wicket.ajax.AbstractAjaxTimerBehavior.onTimer
On Thu, Jul 2, 2015 at 6:11 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:
The change is rather big:
https://github.com/sebfz1/wicket-jquery-ui/commit/e94f89d8f07f2b1af2b327a4aaec5ddd4b1400af
I guess many other methods will need to be changed too if one needs to
use
them with WebSocket.
The improvement in the Wicket API looked so innocent ...
Martin Grigorov
Freelancer. Available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
