I see. This doesn't currently exist in a single public API. There are
two things that sound relevant:
PageFlowStack.destroy() (public)
InternalUtils.removeCurrentPageFlow() (internal)
I think it would be worth making removeCurrentPageFlow() public, and/or
adding a method that does both. Think that would work?
Rich
Carlin Rogers wrote:
Here's some more info I got...
"To clarify the discussion a bit, the functionality I'm looking for is
really completely outside of the whole pageflow stack. It would be used by
a portal when servicing requests where there is no portal state being
loaded, which SHOULD result in a pristine state being entered for all
portlets. In the case of pageflows, this means a completely new pageflow
instance. The important thing though, is that the pageflow itself is not
the initiator of this, it's the portal."
Hope this helps.
On 1/13/06, Daryl Olander <[EMAIL PROTECTED]> wrote:
Actually, I don't think this happens from A (It might happen inside of C).
I don't actually understand the details of the environment that this is
being requested.
On 1/13/06, Rich Feit <[EMAIL PROTECTED]> wrote:
Ah. Can A know about it? I mean, can A have an action that calls its
own remove() method, or is this supposed to be external to A?
Daryl Olander wrote:
I believe the requirement is to actually create a new A (blowing away
the
whole current stack)
On 1/13/06, Rich Feit <[EMAIL PROTECTED]> wrote:
I'm not sure I'm understanding this correctly. Let's say we have a
nesting stack A-B-C, where A is the "oldest" page flow and C is the
most
recent. Do we want to get back to A, blowing away B and C? If so,
then
the easiest thing to do would be to execute any action explicitly on
the
topmost page flow, e.g., path="/path/to/a/begin.do".
If that's not it (I have a feeling I might be way off here :) ), let
me
know...
Rich
Daryl Olander wrote:
So my understanding of this is that there is a request for publically
exposing an API that would allow the current page flow stack to be
blown
away so that the next request would generate new instances of the top
most
page flow and all nesting would be lost.
On 1/12/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
Hey Rich,
Is there a good mechanism for resetting a page flow instance when
the
page
flow is down in a nested page flow? I.E. a way to get back to the
begin
action of the main page flow. Here's the scenario...
In a portal there may be some state associated to a page flow that
they
would manage as well as what we have stuck in the session. When
they
reset
state, they'd like to end up back at the begin action of the page
flow.
This
works for a non-nested page flow.
However, for nested flows, I think that with the page flow instance
keeping
a reference to the "current" page flow, in this case the nested
flow,
and
they try to reset state on the request, they get the begin page of
the
nested flow instead of the original page flow begin.
Do we have something in our API to "reset" a page flow instance
itself
or
even just blow away the instance that gets stored in the
session? Something
to call so there's no stale state. If not, do you have a suggestion
as
to
what might be implemented?
Thanks,
Carlin
