Messages triggered using onChange in a ModalWindow
Hi group, Consider the follow situation: - A ModalWindow is shown using a AjaxFormSubmitBehavior on the onchange of an inputfield. The ModalWindow has a informative message and an Ok button for the user to click if the message is read and understood. Pretty much comparable to a properly styled javascript alert. - Say user enters that fields, types some text and doesn't leave the field (so onchange is not triggered!) - Say the user now clicks a (non-ajax) SubmitButton or SubmitLink - The onchange is now triggered by the browser, so the AJAX request is started (because the focus is switched to the form button) - At the same time, the browser does a normal HTTP POST (triggered by the button click) - Of course, this leads to unwanted behavior, depending on how fast the ajax response is sent and processed. The simple fix would seem to change the buttons and links to their AJAX equivalent, with leads to deterministic behavior (since the ajax events are queued), but still unwanted behavior: an ugly 'are you sure you want to navigate away from this page' confirmation is shown. If we turn the confirmation off, the page changes even if the user doesn't click the Ok button. How can we prevent this? I think the root of the problem is that it seems hard to prevent a AjaxFormSubmitBehavior and a 'normal' form submit being executed directly after each other. Is there some way to prevent additional ajax (submit) events from being queued if there is still a running event? Or are we going at it the wrong way? Regards, Vincent
Re: Size of ListView
Hi Igor,
Excellent suggestion! It took some experimenting, but we managed to get it
to work.
add(new PropertyListViewMonthAmount(month, new
XListViewModel(x)) {
{
setReuseItems(false);
setVersioned(false);
}
@Override
protected void populateItem(final ListItemMonthAmount item) {
// ... }
@Override
protected void onDetach() {
removeAll();
super.onDetach();
}
});
The gotcha's:
- modifying the component tree AFTER rendering increments the page version,
which is obviously unwanted and causes fatal errors (since the form action
still points the old version of the page which is not stored in the
session).
- disabling versioning of the list view circumvents this. It seems pretty
logical to me - since it is to be re-populated upon each request (it's
pretty much stateless), it should not impact the version.
I'm feeling pretty good about this approach - we'll probably make a separate
ListView component out of it. Do you have any thoughts on it? Should I
create a feature request in Jira to change the implementation of ListView to
behave like I described?
Regards,
Vincent.
On 22 July 2010 18:41, Igor Vaynberg igor.vaynb...@gmail.com wrote:
what about onDetach() ?
-igor
On Thu, Jul 22, 2010 at 6:17 AM, Danny van Bruggen tsuih...@gmail.com
wrote:
No, we can't change the component tree in onAfterRender - Wicket
complains that it cannot increase the page version after rendering.
On 7/21/10, Vincent Lussenburg vincent.lussenb...@gmail.com wrote:
I remember trying that, but getting slapped by wicket for trying to
change
the component tree after rendering.. Or am I missing something?
We'll doublecheck it tomorrow.
Groet,
Vincent
On Jul 21, 2010, at 18:37, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
if the data is strictly read-only and does not contain any links you
can try removing the list items in afterrender()
-igor
On Wed, Jul 21, 2010 at 7:50 AM, Danny van Bruggen tsuih...@gmail.com
wrote:
Hello all,
We're developing a non-Ajax application that displays a bunch of big
tables - about five columns, 300 rows. Since session size was
increasing a lot, we looked into the cause of it, and (after making
everything detachable and switching to PropertyListModel) found out
that the ListItems of each ListView still accounted for about 100k.
Since all the data in the tables is read only, we're wondering if we
can skip serializing the ListItems. Is this possible?
Is there another approach?
Danny van Bruggen
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Size of ListView
I suppose so.. Well, at least it's a loophole for big chucks of readonly data.
Thanks for your replies!
Groet,
Vincent
On Jul 26, 2010, at 17:22, Igor Vaynberg igor.vaynb...@gmail.com wrote:
no, this will not work for the larger usecase. like i mentioned
before, if you place links or textfields or anything but labels into
listitems they will not work.
-igor
On Mon, Jul 26, 2010 at 3:41 AM, Vincent Lussenburg
vincent.lussenb...@gmail.com wrote:
Hi Igor,
Excellent suggestion! It took some experimenting, but we managed to get it
to work.
add(new PropertyListViewMonthAmount(month, new
XListViewModel(x)) {
{
setReuseItems(false);
setVersioned(false);
}
@Override
protected void populateItem(final ListItemMonthAmount item) {
// ... }
@Override
protected void onDetach() {
removeAll();
super.onDetach();
}
});
The gotcha's:
- modifying the component tree AFTER rendering increments the page version,
which is obviously unwanted and causes fatal errors (since the form action
still points the old version of the page which is not stored in the
session).
- disabling versioning of the list view circumvents this. It seems pretty
logical to me - since it is to be re-populated upon each request (it's
pretty much stateless), it should not impact the version.
I'm feeling pretty good about this approach - we'll probably make a separate
ListView component out of it. Do you have any thoughts on it? Should I
create a feature request in Jira to change the implementation of ListView to
behave like I described?
Regards,
Vincent.
On 22 July 2010 18:41, Igor Vaynberg igor.vaynb...@gmail.com wrote:
what about onDetach() ?
-igor
On Thu, Jul 22, 2010 at 6:17 AM, Danny van Bruggen tsuih...@gmail.com
wrote:
No, we can't change the component tree in onAfterRender - Wicket
complains that it cannot increase the page version after rendering.
On 7/21/10, Vincent Lussenburg vincent.lussenb...@gmail.com wrote:
I remember trying that, but getting slapped by wicket for trying to
change
the component tree after rendering.. Or am I missing something?
We'll doublecheck it tomorrow.
Groet,
Vincent
On Jul 21, 2010, at 18:37, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
if the data is strictly read-only and does not contain any links you
can try removing the list items in afterrender()
-igor
On Wed, Jul 21, 2010 at 7:50 AM, Danny van Bruggen tsuih...@gmail.com
wrote:
Hello all,
We're developing a non-Ajax application that displays a bunch of big
tables - about five columns, 300 rows. Since session size was
increasing a lot, we looked into the cause of it, and (after making
everything detachable and switching to PropertyListModel) found out
that the ListItems of each ListView still accounted for about 100k.
Since all the data in the tables is read only, we're wondering if we
can skip serializing the ListItems. Is this possible?
Is there another approach?
Danny van Bruggen
-
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
-
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: Size of ListView
I remember trying that, but getting slapped by wicket for trying to change the component tree after rendering.. Or am I missing something? We'll doublecheck it tomorrow. Groet, Vincent On Jul 21, 2010, at 18:37, Igor Vaynberg igor.vaynb...@gmail.com wrote: if the data is strictly read-only and does not contain any links you can try removing the list items in afterrender() -igor On Wed, Jul 21, 2010 at 7:50 AM, Danny van Bruggen tsuih...@gmail.com wrote: Hello all, We're developing a non-Ajax application that displays a bunch of big tables - about five columns, 300 rows. Since session size was increasing a lot, we looked into the cause of it, and (after making everything detachable and switching to PropertyListModel) found out that the ListItems of each ListView still accounted for about 100k. Since all the data in the tables is read only, we're wondering if we can skip serializing the ListItems. Is this possible? Is there another approach? Danny van Bruggen - 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: Testing wicket pages in isolation (wickettester)
Hi Kent, Oh yeah, that's also a possibility. However, the constructor code would still be executed here. So I'd still needs to records some mocks for that. Thanks for your reply! Groet, Vincent On May 13, 2010, at 8:03, Kent Tong k...@cpttm.org.mo wrote: Hi Vincent, You can use a page navigator interface. See the example Checking if a Wicket page is passing the correct data to the next page on http://wicketpagetest.sourceforge.net/examples.html -- Kent Tong, Msc, PMP, CISSP, ITIL Foundation Senior manager of IT dept, CPTTM Authorized training for Adobe, Aruba, Cisco, Microsoft, SUN - 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
Testing wicket pages in isolation (wickettester)
Hi all,
I'm sending this page to check if I've drawn the correct conclusions on
testing wicket pages in isolation.
The situation is as follows: we have a number of pages that work on the same
model object. The object is passed from page to page in page transitions. So
for example, when the 'next' button is pressed, setResponsePage(new
NextPage(modelObject)); is called. The constructor of these pages explicitly
require the typed object.
We're testing these pages using WicketTester. What happens now is that if an
action is done to invoke the next page, that page is also constructed
(normal POJO behavior) and rendered (by WicketTester). This means we have to
prepare our mocks for any code executed in the next page as well. That
violates the DRY principle, we'd rather test the page in isolation and only
check that the page is constructed with the correct argument. The following
solutions came to mind:
1) Change the constructor to accept PageParameters instead in which we put
the model object we wish to pass and use the IPageFactory to construct the
page. In tests, we can mock the IPageFactory to expect the call and return a
DummyHomePage instead. Downside is that production code is less obvious -
contracts are less strict.
2) Place the code that creates the pages in a protected method we can
override in test mode. So, in production code we have:
WebPage createNextPage(final ModelObject modelObject) {
return new NextPage(orderModel.getObject());
}
In test code we have:
class TestableNextPage extends NextPage {
[]
@Override
WebPage createNextPage(final ModelObject modelObject) {
nextPageWasCalled = true;
return new DummyHomePage();
}
}
3) Create our own PageFactory specialization that supports
createPage(Class? extends Page pageClass, Object...
constructorParameters))... but I have a feeling that there's a reason it's
not included in Wicket.
I find solution 2) now least intrusive in production code so we're using
this approach, currently but I'm not overly enthusiastic about it.
Are there any options I'm overlooking?
Thanks for your insights,
Vincent.
Re: Testing wicket pages in isolation (wickettester)
Ok, thanks for your reply Igor!
Regards,
Vincent
On May 12, 2010, at 17:44, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i would go with 2
the problem here is that wicket tester is designed to render the
pages, if it didnt then all you would have to do is make sure that a
pagerequesttarget with the correct page was set on the request cycle.
-igor
On Wed, May 12, 2010 at 1:06 AM, Vincent Lussenburg
vincent.lussenb...@gmail.com wrote:
Hi all,
I'm sending this page to check if I've drawn the correct
conclusions on
testing wicket pages in isolation.
The situation is as follows: we have a number of pages that work on
the same
model object. The object is passed from page to page in page
transitions. So
for example, when the 'next' button is pressed, setResponsePage(new
NextPage(modelObject)); is called. The constructor of these pages
explicitly
require the typed object.
We're testing these pages using WicketTester. What happens now is
that if an
action is done to invoke the next page, that page is also constructed
(normal POJO behavior) and rendered (by WicketTester). This means
we have to
prepare our mocks for any code executed in the next page as well.
That
violates the DRY principle, we'd rather test the page in isolation
and only
check that the page is constructed with the correct argument. The
following
solutions came to mind:
1) Change the constructor to accept PageParameters instead in which
we put
the model object we wish to pass and use the IPageFactory to
construct the
page. In tests, we can mock the IPageFactory to expect the call and
return a
DummyHomePage instead. Downside is that production code is less
obvious -
contracts are less strict.
2) Place the code that creates the pages in a protected method we can
override in test mode. So, in production code we have:
WebPage createNextPage(final ModelObject modelObject) {
return new NextPage(orderModel.getObject());
}
In test code we have:
class TestableNextPage extends NextPage {
[]
@Override
WebPage createNextPage(final ModelObject modelObject) {
nextPageWasCalled = true;
return new DummyHomePage();
}
}
3) Create our own PageFactory specialization that supports
createPage(Class? extends Page pageClass, Object...
constructorParameters))... but I have a feeling that there's a
reason it's
not included in Wicket.
I find solution 2) now least intrusive in production code so we're
using
this approach, currently but I'm not overly enthusiastic about it.
Are there any options I'm overlooking?
Thanks for your insights,
Vincent.
-
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
Error reporting on locked page maps, revisited
Hi all, I kindly request you to take a look at the following issue: http://issues.apache.org/jira/browse/WICKET-2796 It's a small issue, but if you like the solution, I'll be happy to create a patch for it. If not, you can go ahead and close it as a won't-fix ;-). Kind regards, Vincent.
