Re: Wicket7: MediaComponent and Source classes
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?
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
Re: Wicket7: MediaComponent and Source classes
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
Re: Wicket7: MediaComponent and Source classes
Hi Sven, On Fri, Jul 10, 2015 at 12: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. If it helps, I could create a pull-request for the relevant methods in wicket-jquery-ui. Thank you very much for your offer but I will handle it :) Sven
Re: onBeforeRender getting called twice
Yes, It is getting called twice. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/onBeforeRender-getting-called-twice-tp4671575p4671577.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onBeforeRender getting called twice
Hi, Put a breakpoint at WicketFilter#doFilter() and see whether it is called twice. If it is called once and #onBeforeRender() is executed twice then please create a quickstart and attach it to JIRA so we can investigate. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jul 10, 2015 at 3:11 PM, avchavan avinash.cha...@yahoo.co.in wrote: Hi, I am experiencing a weird scenario wherein the onBeforeRender method gets called twice (request is coming as a HTTP request via a standalone API through webService). I am using a Wizard. Same code is used in regular application as well which works without a problem. What could be a possible issue here? I've checked in firebug and i dont see multiple calls to server from browser. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/onBeforeRender-getting-called-twice-tp4671575.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onBeforeRender getting called twice
So, two requests are made. Everything seems to be OK from Wicket point of view. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jul 10, 2015 at 3:36 PM, avchavan avinash.cha...@yahoo.co.in wrote: Yes, It is getting called twice. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/onBeforeRender-getting-called-twice-tp4671575p4671577.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
onBeforeRender getting called twice
Hi, I am experiencing a weird scenario wherein the onBeforeRender method gets called twice (request is coming as a HTTP request via a standalone API through webService). I am using a Wizard. Same code is used in regular application as well which works without a problem. What could be a possible issue here? I've checked in firebug and i dont see multiple calls to server from browser. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/onBeforeRender-getting-called-twice-tp4671575.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onBeforeRender getting called twice
Is there a way to check why it is being called twice? Or from where the second call is being made? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/onBeforeRender-getting-called-twice-tp4671575p4671579.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicket-annotations and page mounting
Hi, I'm using wicket-annotations and I've added: newAnnotatedMountScanner().scanPackage(com.foo.web.pages).mount(this); in my Application class. My page classes all have: @MountPath(value =summary) However, I want to adjust the pages to not use query parameters like account=5 and use / like account/5 instead. Is there a way to set this across the app, just like scanPackage, or do I have to set this on each page in my application? I'm using latest Wicket 6. Thanks, Jason
