Re: Expire page upon session timeout
Thanks for the reference. This is exactly what I want! Regards Robin From: Martin Grigorov To: "users@wicket.apache.org" ; Robin Shine Sent: Thursday, September 18, 2014 11:53 PM Subject: Re: Expire page upon session timeout Hi, >From yesterday: http://markmail.org/message/jjhhmhcwg5zalgzm Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Sep 18, 2014 at 5:49 PM, Robin Shine wrote: > Hi, > > > When an ajax link is clicked after session is timed out, Wicket 1.6 now > refreshes the page silently instead of throwing the PageExpiredException. > This sometimes causes confusions and even can lead to page being refreshed > incorrectly with wrong query parameters. To avoid the confusion, I'd like > to redirect to the session expired page explicitly telling the user that > session is timed out. Is there any way to configure Wicket 1.6 to work in > this way? > > Thanks for helping. > > > Regards > Robin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Expire page upon session timeout
Hi, When an ajax link is clicked after session is timed out, Wicket 1.6 now refreshes the page silently instead of throwing the PageExpiredException. This sometimes causes confusions and even can lead to page being refreshed incorrectly with wrong query parameters. To avoid the confusion, I'd like to redirect to the session expired page explicitly telling the user that session is timed out. Is there any way to configure Wicket 1.6 to work in this way? Thanks for helping. Regards Robin
Re: Avoid calling Page.onInitialize if page constructor throws an exception
Hi Sven,
An issue has been created for this with a quickstart:
https://issues.apache.org/jira/browse/WICKET-5546
Regards
Robin
From: Sven Meier
To: users@wicket.apache.org
Sent: Friday, March 28, 2014 4:22 PM
Subject: Re: Avoid calling Page.onInitialize if page constructor throws an
exception
Hi Robin,
we should try to improve that. Please create a new issue with a quickstart.
Thanks
Sven
On 03/28/2014 09:16 AM, Robin Shine wrote:
> Hi Sven,
>
> Thanks for looking into this. I started a new wicket project from scratch
> using Wicket maven archetype, and it does work as expected! Then I checked
> into my project to find the difference, and tt turns out that this issue will
> occur as long as below code is added in wicket WebApplication.init():
>
>
> getComponentInstantiationListeners().add(new
>IComponentInstantiationListener() {
>
> @Override
> public void onInstantiation(Component component) {
> component.add(new Behavior() {
>
> });
> }
>
> });
>
> It seems that the instantiation listener adds the behavior to the page at
> very start of the page constructor, and then the page is marked as dirty to
> cause onInitialize() being called afterwards. Is this a bug or expected
> behavior?
>
>
> Regards
> Robin
>
>
>
>
> From: Sven Meier
> To: users@wicket.apache.org
> Sent: Thursday, March 27, 2014 10:49 PM
> Subject: Re: Avoid calling Page.onInitialize if page constructor throws an
> exception
>
>
> Hi,
>
> #onInitialize() is not called here with 6.14.0 and 6.15.0-SNAPSHOT.
>
> Regards
> Sven
>
>
> On 03/27/2014 03:30 PM, Robin Shine wrote:
>> Hi All,
>>
>> We are glad to see that the issue WICKET-5387 (Page#onInitialize called
>> after an exception in the constructor of Page) has been resolved in 6.13.0.
>> However when I tried this version (and 6.14.0) with below code, the issue
>> still exist:
>>
>> public class TestPage extends WebPage {
>>
>> public TestPage() {
>> throw new RuntimeException("exception");
>> }
>>
>> @Override
>> protected void onInitialize() {
>> super.onInitialize();
>>
>> System.out.println("onInitialize");
>> }
>>
>> }
>>
>> As you can see from above code, I intentionally throws an exception in
>> TestPage constructor and hoping that onInitialize() method is not called
>> when I visit that page. But the result is that "onInitialize" is still
>> getting called in this case. Am I understanding WICKET-5387 incorrectly? And
>> is there any approach to prevent onInitialize() from being called in case of
>> a constructor exception? We want this as onInitialize() might rely on some
>> params setup in the constructor, and calling onInitialize() will lead to
>> other exceptions hiding exceptions thrown in constructor.
>>
>> Regards
>>
>> Robin
>>
>
> -
> 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: Avoid calling Page.onInitialize if page constructor throws an exception
Hi Sven,
Thanks for looking into this. I started a new wicket project from scratch using
Wicket maven archetype, and it does work as expected! Then I checked into my
project to find the difference, and tt turns out that this issue will occur as
long as below code is added in wicket WebApplication.init():
getComponentInstantiationListeners().add(new
IComponentInstantiationListener() {
@Override
public void onInstantiation(Component component) {
component.add(new Behavior() {
});
}
});
It seems that the instantiation listener adds the behavior to the page at very
start of the page constructor, and then the page is marked as dirty to cause
onInitialize() being called afterwards. Is this a bug or expected behavior?
Regards
Robin
From: Sven Meier
To: users@wicket.apache.org
Sent: Thursday, March 27, 2014 10:49 PM
Subject: Re: Avoid calling Page.onInitialize if page constructor throws an
exception
Hi,
#onInitialize() is not called here with 6.14.0 and 6.15.0-SNAPSHOT.
Regards
Sven
On 03/27/2014 03:30 PM, Robin Shine wrote:
> Hi All,
>
> We are glad to see that the issue WICKET-5387 (Page#onInitialize called after
> an exception in the constructor of Page) has been resolved in 6.13.0. However
> when I tried this version (and 6.14.0) with below code, the issue still exist:
>
> public class TestPage extends WebPage {
>
> public TestPage() {
> throw new RuntimeException("exception");
> }
>
> @Override
> protected void onInitialize() {
> super.onInitialize();
>
> System.out.println("onInitialize");
> }
>
> }
>
> As you can see from above code, I intentionally throws an exception in
> TestPage constructor and hoping that onInitialize() method is not called when
> I visit that page. But the result is that "onInitialize" is still getting
> called in this case. Am I understanding WICKET-5387 incorrectly? And is there
> any approach to prevent onInitialize() from being called in case of a
> constructor exception? We want this as onInitialize() might rely on some
> params setup in the constructor, and calling onInitialize() will lead to
> other exceptions hiding exceptions thrown in constructor.
>
> Regards
>
> Robin
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Avoid calling Page.onInitialize if page constructor throws an exception
Hi All,
We are glad to see that the issue WICKET-5387 (Page#onInitialize called after
an exception in the constructor of Page) has been resolved in 6.13.0. However
when I tried this version (and 6.14.0) with below code, the issue still exist:
public class TestPage extends WebPage {
public TestPage() {
throw new RuntimeException("exception");
}
@Override
protected void onInitialize() {
super.onInitialize();
System.out.println("onInitialize");
}
}
As you can see from above code, I intentionally throws an exception in TestPage
constructor and hoping that onInitialize() method is not called when I visit
that page. But the result is that "onInitialize" is still getting called in
this case. Am I understanding WICKET-5387 incorrectly? And is there any
approach to prevent onInitialize() from being called in case of a constructor
exception? We want this as onInitialize() might rely on some params setup in
the constructor, and calling onInitialize() will lead to other exceptions
hiding exceptions thrown in constructor.
Regards
Robin
Re: Possible optimization of page store manager
Hi Martin, Thanks for your comment. My previous test of non-ajax action link only involves model change so version is not changed. If I replace parts of the page or call page.dirty() directly, the version does changed, and this makes my modfication no longer valid as I in this case Wicket directly uses instances cached in session to make the change and this makes it impossible to know version being changed by comparing cached instance and touched instance (as they always point to same object). Since ajax requests can still be optimized to only save last state of the instance before switching to new instance (although my previous modification does not work), I will further investigate this to see if this can be implemented. Regards Robin --- On Tue, 6/11/13, Martin Grigorov wrote: From: Martin Grigorov Subject: Re: Possible optimization of page store manager To: "users@wicket.apache.org" Date: Tuesday, June 11, 2013, 7:05 PM Hi, On Tue, Jun 11, 2013 at 1:23 PM, Robin Shine wrote: > Hi All, > > We are using Wicket to develop our web application product (QuickBuild) > for six years, and this makes our life a lot easier when comes to maintain > our code base due to Wicket's component approach and type safe nature of > Java. > > As our product gets more used in companies, it is not uncommon that > thousands of users are accessing the application concurrently, and at peak > time the server sometimes gets stressed to have slow response time. Our > benchmark shows that offen the server is busy serializing pages. This is > not strange as our application uses ajax heavily and every ajax call to the > server triggers the page store to persist (serialize and write) the whole > page on disk. > > To my understanding, Wicket serializes/saves stateful pages for purpose of > back button support. At commit stage of every request, all touched pages > will be put into session cache, and also get persisted via page store. This > mechanism works but results in a lot of unnecessary page persistence. To > explain it, assume below workflow: > 1. User loads the stateful page and wicket creates a page instance to put > in session cache, as well as persist to disk. > 2. User clicks some action links (either ajax or non-ajax) subsequently to > update parts of the page, but still remains in the same page instance, and > the url displayed in browser remains unchanged. For every request, Wicket > updates the page instance, put it into session cache, and finally persist > it to disk. > There is a difference in the behavior between Ajax and non-Ajax request. When non-Ajax - Wicket creates a new version of the page (unless #isVersioned() returns false) and stores it. So going back in the history will go over all versions/states of the page instance. When Ajax - the version (the pageId) is not incremented and the last state *overrides* the state in the page store. Later when/if the user goes back there will be only one display of that page. > 3. User clicks some other links to cause new page instance being created, > and Wicket does the same to put new instance in session cache and persist > the new instance. > > Here in step 2, page persistence seems unnecessary to me except for the > last request. That is to say, if a page instance is touched by many > requests before switching to a different page instance, only the last touch > has to persist the instance. This is because when user goes back to > previous page instance, only the last saved state of that instance will be > used. > > Based on this assumption, I modified method "storeTouchedPages" of > PageStoreManager.java to compare ids of previous page instances (stored in > session cache) and touched page instances. If they are different, persist > the previous page instances. I tested the modification with several cases > of page refreshing/backing and it seems that they all work correctly. > > Although I used Wicket for some time, I seldomly digged into Wicket > internals. So probably I have missed some important factors when assuming > above. Can someone here take a look at attached modification and kindly let > me know if this is meaningful? > At the moment serializing of the page (via JavaSerializer) is synchronous, i.e. it is executed in the http worker thread. The write to the disk is asynchronous (see AsynchronousDataStore) and is done in a different thread, so the http thread doesn't have to wait for the actual write to the disk. Maybe we can make the serialization in a separate thread too. > > Thanks > Robin > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
Re: Possible optimization of page store manager
Hi Martijn, Yes I will if the modification is valid. Right now Martin pointed to me that non-ajax action link also cause version changes, and my previous test does not cover this as I only updated model in my action link so version is not changed. I will further investigate this. Regards Robin --- On Tue, 6/11/13, Martijn Dashorst wrote: From: Martijn Dashorst Subject: Re: Possible optimization of page store manager To: users@wicket.apache.org Date: Tuesday, June 11, 2013, 6:48 PM Hi Robin, Thanks for your thoughts! Can you create a JIRA ticket and attach the path to it? The patch didn't make it through to the mailing list, and things tend to get lost anyway due to the amount of traffic on this list. Martijn On Tue, Jun 11, 2013 at 12:23 PM, Robin Shine wrote: > Hi All, > > We are using Wicket to develop our web application product (QuickBuild) > for six years, and this makes our life a lot easier when comes to maintain > our code base due to Wicket's component approach and type safe nature of > Java. > > As our product gets more used in companies, it is not uncommon that > thousands of users are accessing the application concurrently, and at peak > time the server sometimes gets stressed to have slow response time. Our > benchmark shows that offen the server is busy serializing pages. This is > not strange as our application uses ajax heavily and every ajax call to the > server triggers the page store to persist (serialize and write) the whole > page on disk. > > To my understanding, Wicket serializes/saves stateful pages for purpose of > back button support. At commit stage of every request, all touched pages > will be put into session cache, and also get persisted via page store. This > mechanism works but results in a lot of unnecessary page persistence. To > explain it, assume below workflow: > 1. User loads the stateful page and wicket creates a page instance to put > in session cache, as well as persist to disk. > 2. User clicks some action links (either ajax or non-ajax) subsequently to > update parts of the page, but still remains in the same page instance, and > the url displayed in browser remains unchanged. For every request, Wicket > updates the page instance, put it into session cache, and finally persist > it to disk. > 3. User clicks some other links to cause new page instance being created, > and Wicket does the same to put new instance in session cache and persist > the new instance. > > Here in step 2, page persistence seems unnecessary to me except for the > last request. That is to say, if a page instance is touched by many > requests before switching to a different page instance, only the last touch > has to persist the instance. This is because when user goes back to > previous page instance, only the last saved state of that instance will be > used. > > Based on this assumption, I modified method "storeTouchedPages" of > PageStoreManager.java to compare ids of previous page instances (stored in > session cache) and touched page instances. If they are different, persist > the previous page instances. I tested the modification with several cases > of page refreshing/backing and it seems that they all work correctly. > > Although I used Wicket for some time, I seldomly digged into Wicket > internals. So probably I have missed some important factors when assuming > above. Can someone here take a look at attached modification and kindly let > me know if this is meaningful? > > Thanks > Robin > > > - > 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
Possible optimization of page store manager
Hi All, We are using Wicket to develop our web application product (QuickBuild) for six years, and this makes our life a lot easier when comes to maintain our code base due to Wicket's component approach and type safe nature of Java. As our product gets more used in companies, it is not uncommon that thousands of users are accessing the application concurrently, and at peak time the server sometimes gets stressed to have slow response time. Our benchmark shows that offen the server is busy serializing pages. This is not strange as our application uses ajax heavily and every ajax call to the server triggers the page store to persist (serialize and write) the whole page on disk. To my understanding, Wicket serializes/saves stateful pages for purpose of back button support. At commit stage of every request, all touched pages will be put into session cache, and also get persisted via page store. This mechanism works but results in a lot of unnecessary page persistence. To explain it, assume below workflow: 1. User loads the stateful page and wicket creates a page instance to put in session cache, as well as persist to disk. 2. User clicks some action links (either ajax or non-ajax) subsequently to update parts of the page, but still remains in the same page instance, and the url displayed in browser remains unchanged. For every request, Wicket updates the page instance, put it into session cache, and finally persist it to disk. 3. User clicks some other links to cause new page instance being created, and Wicket does the same to put new instance in session cache and persist the new instance. Here in step 2, page persistence seems unnecessary to me except for the last request. That is to say, if a page instance is touched by many requests before switching to a different page instance, only the last touch has to persist the instance. This is because when user goes back to previous page instance, only the last saved state of that instance will be used. Based on this assumption, I modified method "storeTouchedPages" of PageStoreManager.java to compare ids of previous page instances (stored in session cache) and touched page instances. If they are different, persist the previous page instances. I tested the modification with several cases of page refreshing/backing and it seems that they all work correctly. Although I used Wicket for some time, I seldomly digged into Wicket internals. So probably I have missed some important factors when assuming above. Can someone here take a look at attached modification and kindly let me know if this is meaningful? Thanks Robin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Back button not work in Wicket 1.5.3 when component structure is not changed
I will use modelChanged() as you suggested. Thanks for the community, my
question always get answered very quickly, :D
In case you are interested, here is another wicket powered product: QuickBuild,
a continuous integration and release management server. Initially I
chose Tapestry for the UI layer. Starting from QuickBuild 2.0, I
switched to Wicket since it is very easy to contribute web UI via
plugins due to the fact that Wicket page can be dynamically composed.
Regards
Robin
From: Martin Grigorov
To: users@wicket.apache.org
Sent: Thursday, December 8, 2011 7:31 PM
Subject: Re: Back button not work in Wicket 1.5.3 when component structure is
not changed
Actually the important method is modelChanging(). It calls #dirty() for you.
In the code below there is no change in the state managed by Wicket (a
change in a model with setDefaultModel[Object]()) and that's the
reason the request doesn't trigger new page version.
On Thu, Dec 8, 2011 at 12:27 PM, James Carman
wrote:
> modelChanged()?
>
> Sent from tablet device. Please excuse typos and brevity.
> On Dec 8, 2011 12:58 AM, "Dan Retzlaff" wrote:
>
>> Hi, Robin. I am not a core developer, but I believe this is as designed. If
>> you want the page version to be incremented, you can call Page#dirty() in
>> your onClick(). Otherwise the page version only advances when the component
>> hierarchy changes or when a component's model changes.
>>
>> On Wed, Dec 7, 2011 at 8:24 PM, Robin Shine wrote:
>>
>> > Hi All,
>> >
>> >
>> > In Wicket 1.5.3, I create a very simple page containing a label and a
>> > link, when the link is clicked, it increases a counter, and change model
>> > value of the label. Thus the counter on the page will increase each time
>> > the link is clicked. For instance, the initial value displayed is 0, and
>> > after three clicks, the page displays value 3. However, the url remains
>> > unchanged while clicking the link, and hitting a back button at this time
>> > will display the page before displaying value 0, instead of displaying
>> > value 2.
>> >
>> >
>> > Is this a designed behavior or a bug? The page java code and its template
>> > is like below:
>> >
>> >
>> > TestPage.java:
>> >
>> > public class MyPage extends WebPage {
>> >
>> > private int count;
>> > protected void onInitialize() {
>> > super.onInitialize();
>> > add(new Link("link") {
>> > public void onClick() {
>> > count++;
>> > }
>> > });
>> > add(new Label("label", new AbstractReadOnlyModel() {
>> > public String getObject() {
>> > return String.valueOf(count);
>> > }
>> > }));
>> > }
>> > }
>> >
>> > TestPage.html:
>> >
>> > link
>> > label
>> >
>> >
>> > Thanks for your help.
>> >
>> > Robin
>> >
>>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Back button not work in Wicket 1.5.3 when component structure is not changed
Hi Dan,
Thanks for the quick response. The dirty() method does make the back button
work again.
Regards
Robin
From: Dan Retzlaff
To: users@wicket.apache.org; Robin Shine
Sent: Thursday, December 8, 2011 1:57 PM
Subject: Re: Back button not work in Wicket 1.5.3 when component structure is
not changed
Hi, Robin. I am not a core developer, but I believe this is as designed. If
you want the page version to be incremented, you can call Page#dirty() in
your onClick(). Otherwise the page version only advances when the component
hierarchy changes or when a component's model changes.
On Wed, Dec 7, 2011 at 8:24 PM, Robin Shine wrote:
> Hi All,
>
>
> In Wicket 1.5.3, I create a very simple page containing a label and a
> link, when the link is clicked, it increases a counter, and change model
> value of the label. Thus the counter on the page will increase each time
> the link is clicked. For instance, the initial value displayed is 0, and
> after three clicks, the page displays value 3. However, the url remains
> unchanged while clicking the link, and hitting a back button at this time
> will display the page before displaying value 0, instead of displaying
> value 2.
>
>
> Is this a designed behavior or a bug? The page java code and its template
> is like below:
>
>
> TestPage.java:
>
> public class MyPage extends WebPage {
>
> private int count;
> protected void onInitialize() {
> super.onInitialize();
> add(new Link("link") {
> public void onClick() {
> count++;
> }
> });
> add(new Label("label", new AbstractReadOnlyModel() {
> public String getObject() {
> return String.valueOf(count);
> }
> }));
> }
> }
>
> TestPage.html:
>
> link
> label
>
>
> Thanks for your help.
>
> Robin
>
Back button not work in Wicket 1.5.3 when component structure is not changed
Hi All,
In Wicket 1.5.3, I create a very simple page containing a label and a link,
when the link is clicked, it increases a counter, and change model value of the
label. Thus the counter on the page will increase each time the link is
clicked. For instance, the initial value displayed is 0, and after three
clicks, the page displays value 3. However, the url remains unchanged while
clicking the link, and hitting a back button at this time will display the page
before displaying value 0, instead of displaying value 2.
Is this a designed behavior or a bug? The page java code and its template is
like below:
TestPage.java:
public class MyPage extends WebPage {
private int count;
protected void onInitialize() {
super.onInitialize();
add(new Link("link") {
public void onClick() {
count++;
}
});
add(new Label("label", new AbstractReadOnlyModel() {
public String getObject() {
return String.valueOf(count);
}
}));
}
}
TestPage.html:
link
label
Thanks for your help.
Robin
Re: Page.onPageAttached() never gets called in 1.5?
In the listener method, I had to replace some panels (and those panels in turn creates other panels). Since getPage() can not be invoked in component constructors, it will be necessary to pass the page instance retrieved in listener method as one of component constructor param in order to access page instance there. This might not be a common use case. Anyway, thanks for the extensive infrastructure of Wicket, I can call the onPageAttahched() method by myself by subclassing PersistentManagementPage. Regards Robin --- On Tue, 3/8/11, Igor Vaynberg wrote: From: Igor Vaynberg Subject: Re: Page.onPageAttached() never gets called in 1.5? To: users@wicket.apache.org Cc: "Robin Shine" Date: Tuesday, March 8, 2011, 12:02 AM i dont seem to understand the entire usecase here, if you are running code inside a listener then you can get page via getpage()... -igor On Mon, Mar 7, 2011 at 12:33 AM, Robin Shine wrote: > Hi Igor, > Thanks for the response. "onConfigure" gets called only when the page has to > be rendered. Previously "onPageAttached" can serve as a hook point when page > is loaded from page store even if it is not rendered, for example, when > invoking listener interface on components contained in the page. Although I > can override PagePersistentManager to call the hook by myself, but keeping > this in Wicket 1.5 would be very convenient for some use cases, for example > to get current page instance in component constructor without passing page > instance as a constructor param. > Robin > --- On Mon, 3/7/11, Igor Vaynberg wrote: > > From: Igor Vaynberg > Subject: Re: Page.onPageAttached() never gets called in 1.5? > To: users@wicket.apache.org > Cc: "Robin Shine" > Date: Monday, March 7, 2011, 1:27 PM > > i think this method should be removed from Page, for code that needs > access to a page you can use onInitialize() for one-time code and > onConfigure() for every request. > > -igor > > On Sun, Mar 6, 2011 at 7:33 PM, Robin Shine wrote: >> Hi All, >> We rely on this method to store the page instance being processed into a >> thread local so that we can easily get current page even from component >> constructors. In 1.4 this method is invoked after page is retrieved from >> session store for example when click an ajax link on the page. However in >> 1.5 it never gets called. Is this expected behavior or should I go ahead to >> create a bug? >> ThanksRobin > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Page.onPageAttached() never gets called in 1.5?
Hi Igor, Thanks for the response. "onConfigure" gets called only when the page has to be rendered. Previously "onPageAttached" can serve as a hook point when page is loaded from page store even if it is not rendered, for example, when invoking listener interface on components contained in the page. Although I can override PagePersistentManager to call the hook by myself, but keeping this in Wicket 1.5 would be very convenient for some use cases, for example to get current page instance in component constructor without passing page instance as a constructor param. Robin --- On Mon, 3/7/11, Igor Vaynberg wrote: From: Igor Vaynberg Subject: Re: Page.onPageAttached() never gets called in 1.5? To: users@wicket.apache.org Cc: "Robin Shine" Date: Monday, March 7, 2011, 1:27 PM i think this method should be removed from Page, for code that needs access to a page you can use onInitialize() for one-time code and onConfigure() for every request. -igor On Sun, Mar 6, 2011 at 7:33 PM, Robin Shine wrote: > Hi All, > We rely on this method to store the page instance being processed into a > thread local so that we can easily get current page even from component > constructors. In 1.4 this method is invoked after page is retrieved from > session store for example when click an ajax link on the page. However in 1.5 > it never gets called. Is this expected behavior or should I go ahead to > create a bug? > ThanksRobin
Page.onPageAttached() never gets called in 1.5?
Hi All, We rely on this method to store the page instance being processed into a thread local so that we can easily get current page even from component constructors. In 1.4 this method is invoked after page is retrieved from session store for example when click an ajax link on the page. However in 1.5 it never gets called. Is this expected behavior or should I go ahead to create a bug? ThanksRobin
Re: Wicket:enclosure does not work with navigation toolbar of data table
Hi Anton,
The enclosure tag does not need to have a child attribute if there is only one
child enclosed. OTOH, the problem remains the same even if you add the child
attribute.
Regards
Robin
--- On Thu, 3/19/09, Anton Veretennikov wrote:
From: Anton Veretennikov
Subject: Re: Wicket:enclosure does not work with navigation toolbar of data
table
To: users@wicket.apache.org
Date: Thursday, March 19, 2009, 11:09 PM
wicket:enclosure must have "child" attribute to know which child
component to ask about visibility?
Example:
First
Last
-- Tony
On Thu, Mar 19, 2009 at 4:04 PM, Leszek Gawron wrote:
> Robin Shine wrote:
>>
>> Hi All,
>> It seems that the navigation toolbar of data table component can not be
>> displayed if there is a link on the page surrounded with the
>> wicket:enclosure tag. Here is my very simple test case:
>>
>> TestPage.html:
>>
>> http://www.w3.org/1999/xhtml";>
>>
>>
>>
>>
>> link
>>
>>
>>
>>
>> TestPage.java:
>>
>> package test;
>>
>> import java.io.Serializable;
>> import java.util.ArrayList;
>> import java.util.Iterator;
>> import java.util.List;
>>
>> import
>> org.apache.wicket.extensions.markup.html.repeater.data.table.AbstractColumn;
>> import
>> org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable;
>> import
>> org.apache.wicket.extensions.markup.html.repeater.data.table.NavigationToolbar;
>> import org.apache.wicket.markup.html.WebPage;
>> import org.apache.wicket.markup.html.basic.Label;
>> import org.apache.wicket.markup.html.link.Link;
>> import org.apache.wicket.markup.repeater.Item;
>> import org.apache.wicket.markup.repeater.data.IDataProvider;
>> import org.apache.wicket.model.IModel;
>> import org.apache.wicket.model.Model;
>>
>> public class TestPage extends WebPage { public TestPage() {
>> add(new Link("link") {
>> @Override
>> public void onClick() {
>> } �...@override
>> public boolean isVisible() {
>> return false;
>> }
>> });
>> AbstractColumn[] columns = new AbstractColumn[]{
>> new AbstractColumn(new Model("value")) {
>> public void populateItem(Item cellItem, String componentId, IModel
>> rowModel) {
>> cellItem.add(new Label(componentId, rowModel.getObject().toString()));
>> } },
>> };
>> IDataProvider dataProvider = new IDataProvider() {
>> public Iterator iterator(int first, int count) {
>> List values = new ArrayList();
>> for (int i=0; i> values.add(String.valueOf(i + first));
>> return values.iterator();
>> }
>> public int size() {
>> return 100;
>> }
>> public IModel model(Object object) {
>> return new Model((Serializable) object);
>> }
>> public void detach() {
>> }
>> };
>> DataTable dataTable = new DataTable("data", columns, dataProvider, 10);
>> dataTable.addBottomToolbar(new NavigationToolbar(dataTable));
>> add(dataTable);
>> }
>> }
>>
>> Add this page to a wicket application, then mount and navigate to the
>> page:
>> The navigation toolbar of the data table is not displayed. However if the
>> "wicket:enclosure" tag is removed from the template, the toobar then
>> displays correctly.
>> Is this a bug? Or is there anything obvious I missed?
>
> I stumbled upon exactly the same poblem. The only thing I can tell you: you
> don't need wicket:enclosure in your case. Simply remove the tag and as
> Link.isVisible returns false it will not be rendered.
>
> If you put anything else apart from into wicket:enclosure you should
> see correct behavior.
>
> This probably IS a bug. File a JIRA request for that.
>
> --
> Leszek Gawron
>
> -
> 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: Wicket:enclosure does not work with navigation toolbar of data table
Thanks for the answer.
This is just a simple test case to demonstrate the problem. In the real case, I
have surrounding tags around the link, which needs to be hidden as long as the
link is hidden. I will go to file an issue.
Regards
Robin
--- On Thu, 3/19/09, Leszek Gawron wrote:
From: Leszek Gawron
Subject: Re: Wicket:enclosure does not work with navigation toolbar of data
table
To: users@wicket.apache.org
Date: Thursday, March 19, 2009, 5:04 PM
Robin Shine wrote:
> Hi All,
> It seems that the navigation toolbar of data table component can not be
> displayed if there is a link on the page surrounded with the wicket:enclosure
> tag. Here is my very simple test case:
>
> TestPage.html:
>
> http://www.w3.org/1999/xhtml";>
>
>
>
>
> link
>
>
>
>
> TestPage.java:
>
> package test;
>
> import java.io.Serializable;
> import java.util.ArrayList;
> import java.util.Iterator;
> import java.util.List;
>
> import
> org.apache.wicket.extensions.markup.html.repeater.data.table.AbstractColumn;
> import org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable;
> import
> org.apache.wicket.extensions.markup.html.repeater.data.table.NavigationToolbar;
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.markup.html.basic.Label;
> import org.apache.wicket.markup.html.link.Link;
> import org.apache.wicket.markup.repeater.Item;
> import org.apache.wicket.markup.repeater.data.IDataProvider;
> import org.apache.wicket.model.IModel;
> import org.apache.wicket.model.Model;
>
> public class TestPage extends WebPage { public TestPage() {
> add(new Link("link") {
> @Override
> public void onClick() {
> } @Override
> public boolean isVisible() {
> return false;
> }
> });
> AbstractColumn[] columns = new AbstractColumn[]{
> new AbstractColumn(new Model("value")) {
> public void populateItem(Item cellItem, String componentId, IModel rowModel) {
> cellItem.add(new Label(componentId, rowModel.getObject().toString()));
> } },
> };
> IDataProvider dataProvider = new IDataProvider() {
> public Iterator iterator(int first, int count) {
> List values = new ArrayList();
> for (int i=0; i values.add(String.valueOf(i + first));
> return values.iterator();
> }
> public int size() {
> return 100;
> }
> public IModel model(Object object) {
> return new Model((Serializable) object);
> }
> public void detach() {
> }
> };
> DataTable dataTable = new DataTable("data", columns, dataProvider, 10);
> dataTable.addBottomToolbar(new NavigationToolbar(dataTable));
> add(dataTable);
> }
> }
>
> Add this page to a wicket application, then mount and navigate to the page:
> The navigation toolbar of the data table is not displayed. However if the
> "wicket:enclosure" tag is removed from the template, the toobar then displays
> correctly.
> Is this a bug? Or is there anything obvious I missed?
I stumbled upon exactly the same poblem. The only thing I can tell you: you
don't need wicket:enclosure in your case. Simply remove the tag and as
Link.isVisible returns false it will not be rendered.
If you put anything else apart from into wicket:enclosure you should
see correct behavior.
This probably IS a bug. File a JIRA request for that.
-- Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax postcall handler does not get called every time
Hi Matt, Thanks for your quick answer. Although in this simple case, it is enough to only update the count label. However in my application, it is necessary to update the whole region including the component initiating the ajax action. One scenario is that I've written a treetable component based on table structure, and it encloses ajax links used to expand/collpase tree nodes. In the event handler of thse links, I modify tree structure to satisfy node expanding/collapsing, and add the whole treetable component to the ajax request target for simplicity reason. >From your words, it seems that it is not safe to use Wicket Ajax this way. >However, my application uses this "pattern" extensively. Are there any other >approaches for my scenario? Regards. Robin Matthew Young <[EMAIL PROTECTED]> wrote: The problem is you are ajax updating this whole thing including the nested ajaxlink: link it causes the wicket-ajax js stuff header contributed everytime the link is clicked. Open the ajax debug window to see. This re-init wipe out the postcallhandler install on page load so there is nothing there to call once the link is clicked. I cannot explain why you need to close and re-open the browser for this to happen. It shouldn't work at all. I'm sure Matej and Igor can explain. Change your page to this and only ajax update the "count" then you have no problem: link
Re: Ajax postcall handler does not get called every time
The test page is rather simple, I will paste it here:
TestPage.java:
package com.pmease.quickbuild.test;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.AjaxLink;
import org.apache.wicket.behavior.HeaderContributor;
import org.apache.wicket.markup.html.IHeaderContributor;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.model.AbstractReadOnlyModel;
public class TestPage extends WebPage {
private int count;
public TestPage() {
final WebMarkupContainer container = new
WebMarkupContainer("container");
container.setOutputMarkupId(true);
add(container);
Label label = new Label("count", new AbstractReadOnlyModel() {
public Object getObject() {
return count;
}
});
container.add(label);
container.add(new AjaxLink("link") {
public void onClick(AjaxRequestTarget target) {
count ++;
target.addComponent(container);
}
});
add(new HeaderContributor(new IHeaderContributor() {
public void renderHead(IHeaderResponse response) {
response.renderOnLoadJavascript("Wicket.Ajax.registerPostCallHandler(function(){alert('ajax');});");
}
}));
}
}
TestPage.html:
Test
link
Thanks for your time.
Robin
Matej Knopp <[EMAIL PROTECTED]> wrote: Apache mailing list doesn't support
attachments. You need to create
JIRA issue and attachethe quickstart there.
-Matej
On Sun, Apr 13, 2008 at 4:12 AM, Matthew Young wrote:
> Where is the attachment?
>
--
Resizable and reorderable grid components.
http://www.inmethod.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ajax postcall handler does not get called every time
Hi All, I am facing with a strange issue that the Ajax postcall handler (registered with Wicket.Ajax.registerPostCallHandler) is only called for the first time when browser is closed and opened again, and subsequent calls does not trigger the handler. To reproduce this, please copy the attached test page into your wicket environment, and mount it to an url, for example "http://localhost:8080/test";, then follow below steps: 1. Close ALL instances of your browser. (This step is very important to reproduce the issue) 2. Open your browser, and input the url "http://localhost:8080/test"; into the address bar DIRECTLY, the test page will display with a number, and a link. 3. Click on the link, the number will be increased in an ajax way, and you will see an alert message saying "ajax". This means the post call handler has been executed. 4. Click on the link again, the number will still be increased, which means the ajax call has been executed; however, the alert message won't appear now. Please remember that don't refresh the page during the process; otherwise, the issue will not able to be reproduced . Can somebody shed some light on this? Thanks for your help in advance. Robin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: back button and session state rollback
Hi Matej, Thanks for the response. However storing state in the page might not be suitable in our case, and this state need to be shared by several pages, and storing it into session seems to be a better choice. Regards. Robin Matej Knopp <[EMAIL PROTECTED]> wrote: When user presses back button and clicks a ling to page, it will affect the previous page version. Wicket takes care of this automatically. Can you keep the state in page instead of keeping it in session? -Matej On Jan 10, 2008 11:29 AM, Robin Shine wrote: > Hi, > > I am facing a situation where I need to rollback some state kept in session > when user hits the back button at browser side, and clicks some link which > triggers a server round trip. The usage scenario is as below: > 1. User stays on page1, and the current state saved in session in state1 > 2. User clicks on a link in page1. At server side, the onclick() handler of > the link change session state to state2, and set current page to be page2 by > calling setResponsePage() > 3. Now page2 is displayed at browser. User hits the back button to go back to > page1. > 4. User continues to hit a link in page1 to do something. Of course at server > side, the session state will still be state2. > > Now I am looking for an approach to change the session state to the value > when page1 is first presented to user. I searched the mailing list archive > and found the entry > "http://www.nabble.com/Back-button-and-Database-rollback-to4124044.html#a4124044"; > to be useful. However, as I am using wicket 1.3 which uses > SecondLevelCacheSessionStore, the "addStateChange" approach does not take > effect. > > So is there any other approaches for this problem? > > PS: Storing state in page instead of session solves the back-button problem, > however I can not store state into page as my application is composed of many > pages, and this state should be shared across these pages. > > Thanks. > Robin > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
back button and session state rollback
Hi, I am facing a situation where I need to rollback some state kept in session when user hits the back button at browser side, and clicks some link which triggers a server round trip. The usage scenario is as below: 1. User stays on page1, and the current state saved in session in state1 2. User clicks on a link in page1. At server side, the onclick() handler of the link change session state to state2, and set current page to be page2 by calling setResponsePage() 3. Now page2 is displayed at browser. User hits the back button to go back to page1. 4. User continues to hit a link in page1 to do something. Of course at server side, the session state will still be state2. Now I am looking for an approach to change the session state to the value when page1 is first presented to user. I searched the mailing list archive and found the entry "http://www.nabble.com/Back-button-and-Database-rollback-to4124044.html#a4124044"; to be useful. However, as I am using wicket 1.3 which uses SecondLevelCacheSessionStore, the "addStateChange" approach does not take effect. So is there any other approaches for this problem? PS: Storing state in page instead of session solves the back-button problem, however I can not store state into page as my application is composed of many pages, and this state should be shared across these pages. Thanks. Robin
