Strange issue in RequestCycle

[Kent Tong <ke...@cpttm.org.mo>]

Hi,

In 1.5, the request cycle (indirectly) contains a stack of request handlers.
According to the Java docs, it seems the purpose is to allow a request
handler to execute another request handler in its respond() method by
calling the execute() method in the request cycle. However:

a) There seems to be no code in Wicket doing that and I don't see why
one would want to do that. What's the use case?

b) There is no execute() method in the RequestCycle class at all. So
there is actually no way for a request handler to call execute() on invoke
another. Does it mean that there is inconsistency here?

c) Even if there were a way to execute another request handle inline,
there is only one scheduledAfterCurrent in the request cycle. This would
cause problems of the inlined request handle schedule another handler,
right?




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Strange issue in RequestCycle

[Igor Vaynberg <ig...@gmail.com>]

On Sun, Oct 16, 2011 at 1:51 AM, Kent Tong <ke...@cpttm.org.mo> wrote:
> Hi,
>
> In 1.5, the request cycle (indirectly) contains a stack of request handlers.
> According to the Java docs, it seems the purpose is to allow a request
> handler to execute another request handler in its respond() method by
> calling the execute() method in the request cycle. However:
>
> a) There seems to be no code in Wicket doing that and I don't see why
> one would want to do that. What's the use case?

the usecase is simple, one requesthandler handing work off to another
one. an easy example is a request handler that handles a callback
(such as a link being clicked) scheduling the handler that renders the
page after it handled the click.

> b) There is no execute() method in the RequestCycle class at all. So
> there is actually no way for a request handler to call execute() on invoke
> another. Does it mean that there is inconsistency here?

yep, just fixed the javadoc. there is no execute(), only
scheduleafter() and replaceall()

> c) Even if there were a way to execute another request handle inline,
> there is only one scheduledAfterCurrent in the request cycle. This would
> cause problems of the inlined request handle schedule another handler,
> right?

all scheduled handlers go into a queue and are executed in order.
usually there are only two handlers scheduled - event handler and page
renderer.

-igor

>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org