Re: How exactly does RestartResponseAtInterceptPageException work?
I've been thinking about this in the past. Our use case was a post while not logged in. I guess retaining post data is not really a problem. Since the Restart...Exception is under user control, the application would be responsible for not sending megs and megs. Since there is exactly one request pending in this way, I don't see the problem. as for the rest of the problems: redoing posts would go a long way Thomas On Tue, Feb 24, 2009 at 2:03 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > The problem with returning to the original request is that it can be > anything, including a post. While this is an interesting idea, I think > there are hairy issues to be resolved before this can become in a > workable state. Currently Wicket doesn't support it. > > Hairy stuff: > - retaining post data (for how long?) > - retaining multi-part post (for how long?) > - ajax request... how can you return to that? > - resource request... how can you return to that? > > etc. > > I do like the idea, it is almost continuation support... > > Martijn > > On Thu, Feb 19, 2009 at 5:59 AM, David Leangen wrote: > > > > Jeremy, > > > > Thank you for this. > > > >> To my knowledge, the onClick will not be rerun. > > > > Thank you. > > > > I was not able to find any doc about this anywhere, and I'm not sure > > what the designer's intentions were. > > > > How were you able to find this out? > > > > > >> I would do getPage() in that onClick and send them to > >> the page (passing the getPage()) that does > >> something, then send them back after doing some work. When they click > on > >> the link again, in theory, token shouldn't be null again... > > > > Thanks for the suggestion. That won't exactly work with the flow of my > processes (the example code I gave was very much simplified), but at least > you confirmed that the onClick() does not get rerun, so I can adjust > accordingly. > > > > Thank you! > > > > =David > > > > > > > > > > - > > 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 > Apache Wicket 1.3.5 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Wicket & Eclipse Consulting www.devotek-it.ch thomasmaeder.blogspot.com
Re: How exactly does RestartResponseAtInterceptPageException work?
The problem with returning to the original request is that it can be anything, including a post. While this is an interesting idea, I think there are hairy issues to be resolved before this can become in a workable state. Currently Wicket doesn't support it. Hairy stuff: - retaining post data (for how long?) - retaining multi-part post (for how long?) - ajax request... how can you return to that? - resource request... how can you return to that? etc. I do like the idea, it is almost continuation support... Martijn On Thu, Feb 19, 2009 at 5:59 AM, David Leangen wrote: > > Jeremy, > > Thank you for this. > >> To my knowledge, the onClick will not be rerun. > > Thank you. > > I was not able to find any doc about this anywhere, and I'm not sure > what the designer's intentions were. > > How were you able to find this out? > > >> I would do getPage() in that onClick and send them to >> the page (passing the getPage()) that does >> something, then send them back after doing some work. When they click on >> the link again, in theory, token shouldn't be null again... > > Thanks for the suggestion. That won't exactly work with the flow of my > processes (the example code I gave was very much simplified), but at least > you confirmed that the onClick() does not get rerun, so I can adjust > accordingly. > > Thank you! > > =David > > > > > - > 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 Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How exactly does RestartResponseAtInterceptPageException work?
I think from just playing with it :) On Wed, Feb 18, 2009 at 11:59 PM, David Leangen wrote: > > Jeremy, > > Thank you for this. > > > To my knowledge, the onClick will not be rerun. > > Thank you. > > I was not able to find any doc about this anywhere, and I'm not sure > what the designer's intentions were. > > How were you able to find this out? > > > > I would do getPage() in that onClick and send them to > > the page (passing the getPage()) that does > > something, then send them back after doing some work. When they click on > > the link again, in theory, token shouldn't be null again... > > Thanks for the suggestion. That won't exactly work with the flow of my > processes (the example code I gave was very much simplified), but at least > you confirmed that the onClick() does not get rerun, so I can adjust > accordingly. > > Thank you! > > =David > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Jeremy Levy See my location in real-time: http://seemywhere.com/jeremy
Re: How exactly does RestartResponseAtInterceptPageException work?
Jeremy, Thank you for this. > To my knowledge, the onClick will not be rerun. Thank you. I was not able to find any doc about this anywhere, and I'm not sure what the designer's intentions were. How were you able to find this out? > I would do getPage() in that onClick and send them to > the page (passing the getPage()) that does > something, then send them back after doing some work. When they click on > the link again, in theory, token shouldn't be null again... Thanks for the suggestion. That won't exactly work with the flow of my processes (the example code I gave was very much simplified), but at least you confirmed that the onClick() does not get rerun, so I can adjust accordingly. Thank you! =David - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How exactly does RestartResponseAtInterceptPageException work?
David,
To my knowledge, the onClick will not be rerun. I would do getPage() in
that onClick and send them to the page (passing the getPage()) that does
something, then send them back after doing some work. When they click on
the link again, in theory, token shouldn't be null again...
Jeremy
On Mon, Feb 16, 2009 at 2:27 AM, David Leangen wrote:
> Hi!
>
> Just wondering how this works, precisely, since I've been having some
> intermittent problems.
>
> I have a link that has an onClick() method that looks something like
> this (in principle):
>
> public void onClick()
> {
> String token = checkForToken();
> if( token == null )
>// Do something that will cause token to be non-null next time
>throw new RestartResponseAtInterceptPageException( SomePage.class );
>
> doSomething( token );
> }
>
> During the process of doSomething(), I make the call to
> continueToOriginalDestination. This returns to the URL that includes the
> ITargetListener, so my expectation is that the onClick() above will be
> called again. Since this time checkForToken() returns the token, I can
> continue processing normally.
>
> This is working intermittently for me, so I believe that the way I
> _think_ things work is correct, but it would be really nice for somebody
> to confirm this for me.
>
>
> Thank you!
> =David
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Jeremy Levy
See my location in real-time:
http://seemywhere.com/jeremy
How exactly does RestartResponseAtInterceptPageException work?
Hi!
Just wondering how this works, precisely, since I've been having some
intermittent problems.
I have a link that has an onClick() method that looks something like
this (in principle):
public void onClick()
{
String token = checkForToken();
if( token == null )
// Do something that will cause token to be non-null next time
throw new RestartResponseAtInterceptPageException( SomePage.class );
doSomething( token );
}
During the process of doSomething(), I make the call to
continueToOriginalDestination. This returns to the URL that includes the
ITargetListener, so my expectation is that the onClick() above will be
called again. Since this time checkForToken() returns the token, I can
continue processing normally.
This is working intermittently for me, so I believe that the way I
_think_ things work is correct, but it would be really nice for somebody
to confirm this for me.
Thank you!
=David
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
How exactly does RestartResponseAtInterceptPageException work?
Hi!
Just wondering how this works, precisely.
I have a link that has an onClick() method that looks something like
this (in principle):
public void onClick()
{
String token = checkForToken();
if( token == null )
// Do something that will cause token to be non-null next time
throw new RestartResponseAtInterceptPageException( SomePage.class );
doSomething( token );
}
This was working, now it's not. So, I guess I don't understand the
mechanism after all.
I thought that the URL associated with that onClick() handler (so,
something funky like /top/?wicket:interface=:18:1:::) was returned to
upon continueToOriginalDestination(). In that case, shouldn't my
onClick() above be called upon return? It's not.
Thank you!
=David
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
