Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Thu, 10 Feb 2011 23:10:42 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:
the problem is indeed that you are sharing state between pages which
is not allowed. you are doing it via one page passing in an anonymous
SelectionCallback to another page, which is the same as passing in an
instance of one page to another.
So anonymous classes between pages are a complete no-go in 1.5? We have
used the template method pattern rather extensively in our current
program. Some pages have methods like onPreviousButtonClicked that are
used like this:
[in OriginalPage.java:]
setResponsePage(new SomePage() {
@Override protected void onPreviousButtonClicked() {
setResponsePage(OriginalPage.this);
}
});
There are other methods that do more than just setResponsePage, but
this illustrates the concept. Pretty much exactly like what is done
with such methods in components all the time.
How do you do this without anonymous classes, or have I misunderstood
something?
Thanks
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: [1.5 MIGRATION] State handling / inter-page events / versioning
setResponsePage(new SomePage() {
@Override protected void onPreviousButtonClicked() {
setResponsePage(OriginalPage.this);
}
});
final PageReference pageRef = this.getPageReference();
setResponsePage(new SomePage() {
@Override protected void onPreviousButtonClicked() {
setResponsePage(pageRef.getPage());
}
});
But you still have a reference in the synthesized class.
So the best is to create a proper class that is nested but not a member class:
private static class BackSomePage {
private PageReference pageRef;
public BackSomePage(PageReference pageRef) {
this. pageRef = pageRef;
}
@Override protected void onPreviousButtonClicked() {
setResponsePage(pageRef.getPage());
}
}
- Tor Iver
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Fri, 11 Feb 2011 09:53:21 +0100
Wilhelmsen Tor Iver toriv...@arrive.no wrote:
So the best is to create a proper class that is nested but not a
member class:
private static class BackSomePage {
private PageReference pageRef;
public BackSomePage(PageReference pageRef) {
this. pageRef = pageRef;
}
@Override protected void onPreviousButtonClicked() {
setResponsePage(pageRef.getPage());
}
}
That's what I feared this would come down to. I think this is rather
awkward to use and is definitely a step backwards from 1.4.
I can see the PageReference being necessary - but if one uses
PageReference instead of Page.this, what would the harm be in still
using the anonymous class, apart from the slightly larger memory
footprint?
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
The anon-inner class still keeps a reference to the previous page.
Martijn
On Fri, Feb 11, 2011 at 10:59 AM, Carl-Eric Menzel
cmen...@wicketbuch.de wrote:
On Fri, 11 Feb 2011 09:53:21 +0100
Wilhelmsen Tor Iver toriv...@arrive.no wrote:
So the best is to create a proper class that is nested but not a
member class:
private static class BackSomePage {
private PageReference pageRef;
public BackSomePage(PageReference pageRef) {
this. pageRef = pageRef;
}
@Override protected void onPreviousButtonClicked() {
setResponsePage(pageRef.getPage());
}
}
That's what I feared this would come down to. I think this is rather
awkward to use and is definitely a step backwards from 1.4.
I can see the PageReference being necessary - but if one uses
PageReference instead of Page.this, what would the harm be in still
using the anonymous class, apart from the slightly larger memory
footprint?
Carl-Eric
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
To return the data via JavaScript / JSON only was on my TODO list anyway. I guess now is the time to put it into practice. Thanks for confirming that. Cheers, Daniel On 11.02.2011 08:10, Igor Vaynberg wrote: the problem is indeed that you are sharing state between pages which is not allowed. you are doing it via one page passing in an anonymous SelectionCallback to another page, which is the same as passing in an instance of one page to another. what you should do instead, especially since you already have the popup page calling an ajax method on the opener as a close callback, is pass the selection to the javascript callback method. this way the callback method can pass the selection back to the page when it executes the ajax callback. this way you dont have to share state between page instances. hope this gets you started. -igor On Wed, Feb 9, 2011 at 9:52 AM, Daniel Soneira daniel.sone...@joyn-it.at wrote: Hi fellow Wicketeers, I have some (general) classes that handle the common flow of selecting one / several entities from a search page (as popup). Basically it looks like this: User opens detail page. User clicks on search link. System opens search page (as pop-up). User enters filtering criteria, begins search. User selects one of the shown entities in the result grid. System closes search page. System refreshes detail page (AJAX) with selected entity. Those general classes worked fine with 1.4 but somehow they are not executing as intended anymore with 1.5. The state of my pop-up selection links seems to get lost somehow. I guess it has something to do with the no more existing page maps and the way pages are versioned now? I've attached a quickstart to illustrate my problem (stripped down to a minimum, just a text field instead of real entities). Since I was probably abusing something in 1.4 regarding serialization / page map handling I'm curious to know of some better ways to achieve this. -- Regards, Daniel Soneira www.joyn-it.at - 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
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Fri, 11 Feb 2011 11:51:12 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Especially since this would basically make any kind of anonymous class in a Page impossible. What about anonymous instances of, for example AbstractReadOnlyModel that are created in a page and passed on to its components? And quite possibly also passed on to other pages from there. Is this all going to be forbidden now or am I missing something? Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
On Fri, Feb 11, 2011 at 3:21 PM, Carl-Eric Menzel cmen...@wicketbuch.dewrote: On Fri, 11 Feb 2011 11:51:12 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Especially since this would basically make any kind of anonymous class in a Page impossible. What about anonymous instances of, for example AbstractReadOnlyModel that are created in a page and passed on to its components? And quite possibly also passed on to other pages from there. Is this all going to be forbidden now or am I missing something? There is no difference with 1.4 in this respect. 1.5 behaves the same way as 1.4. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
starting with 1.4 we have advocated that passing page instances to other pages is a bad idea, whether directly or via anonymous classes. -igor On Fri, Feb 11, 2011 at 5:21 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:51:12 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Especially since this would basically make any kind of anonymous class in a Page impossible. What about anonymous instances of, for example AbstractReadOnlyModel that are created in a page and passed on to its components? And quite possibly also passed on to other pages from there. Is this all going to be forbidden now or am I missing something? Carl-Eric - 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
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
What about passing page _references_ to other pages ? Are there any reefs here ? Thanks Igor Vaynberg-2 wrote: starting with 1.4 we have advocated that passing page instances to other pages is a bad idea, whether directly or via anonymous classes. -igor On Fri, Feb 11, 2011 at 5:21 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:51:12 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Especially since this would basically make any kind of anonymous class in a Page impossible. What about anonymous instances of, for example AbstractReadOnlyModel that are created in a page and passed on to its components? And quite possibly also passed on to other pages from there. Is this all going to be forbidden now or am I missing something? Carl-Eric - 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 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/1-5-MIGRATION-State-handling-inter-page-events-versioning-tp3297781p3301716.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: [1.5 MIGRATION] State handling / inter-page events / versioning
no, this is why page references were created -igor On Fri, Feb 11, 2011 at 10:01 AM, Alexander Morozov alexander.v.moro...@gmail.com wrote: What about passing page _references_ to other pages ? Are there any reefs here ? Thanks Igor Vaynberg-2 wrote: starting with 1.4 we have advocated that passing page instances to other pages is a bad idea, whether directly or via anonymous classes. -igor On Fri, Feb 11, 2011 at 5:21 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:51:12 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Fri, 11 Feb 2011 11:06:09 +0100 Martijn Dashorst martijn.dasho...@gmail.com wrote: The anon-inner class still keeps a reference to the previous page. Yes, I know, that's how anonymous classes work. I don't understand why that is now a problem though. It has worked well so far. Especially since this would basically make any kind of anonymous class in a Page impossible. What about anonymous instances of, for example AbstractReadOnlyModel that are created in a page and passed on to its components? And quite possibly also passed on to other pages from there. Is this all going to be forbidden now or am I missing something? Carl-Eric - 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 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/1-5-MIGRATION-State-handling-inter-page-events-versioning-tp3297781p3301716.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [1.5 MIGRATION] State handling / inter-page events / versioning
the problem is indeed that you are sharing state between pages which is not allowed. you are doing it via one page passing in an anonymous SelectionCallback to another page, which is the same as passing in an instance of one page to another. what you should do instead, especially since you already have the popup page calling an ajax method on the opener as a close callback, is pass the selection to the javascript callback method. this way the callback method can pass the selection back to the page when it executes the ajax callback. this way you dont have to share state between page instances. hope this gets you started. -igor On Wed, Feb 9, 2011 at 9:52 AM, Daniel Soneira daniel.sone...@joyn-it.at wrote: Hi fellow Wicketeers, I have some (general) classes that handle the common flow of selecting one / several entities from a search page (as popup). Basically it looks like this: User opens detail page. User clicks on search link. System opens search page (as pop-up). User enters filtering criteria, begins search. User selects one of the shown entities in the result grid. System closes search page. System refreshes detail page (AJAX) with selected entity. Those general classes worked fine with 1.4 but somehow they are not executing as intended anymore with 1.5. The state of my pop-up selection links seems to get lost somehow. I guess it has something to do with the no more existing page maps and the way pages are versioned now? I've attached a quickstart to illustrate my problem (stripped down to a minimum, just a text field instead of real entities). Since I was probably abusing something in 1.4 regarding serialization / page map handling I'm curious to know of some better ways to achieve this. -- Regards, Daniel Soneira www.joyn-it.at - 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
