Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Message-Id: <5.0.2.1.0.20010124161457.024cd230@pop.mail.yahoo.com>
Date: Wed, 24 Jan 2001 17:04:02 -0800
To: struts-user@jakarta.apache.org
From: Rick Horowitz <rickhoro@yahoo.com>
Subject: RE: Any way to dynamically change flow-of-control? 
Cc: curth@motek.com
In-Reply-To: <710B446D10A4D111863700805F9F0C9E2E08D0@motek03.motek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Curt,

I just read through the thread for this message, and your approach sounds 
very interesting.  I'd like to ask you some questions, interspersed below 
if you wouldn't mind...thanks in advance.

At 04:20 PM 1/12/01 -0800, you wrote:
> > I bring this up because struts seems to have gone partway--better than
> > any other framework I've seen--but not all the way in its support of
> > this dialog box metaphor (it uses form beans).  What is now
> > needed is a navigation stack of some kind--perhaps even something that
> > is written/phrased in terms of "traditional" UI metaphors.
>
>I've implemented something like this as follows.
>
>I make frequent use of a metaphor whereby the form contains an edit
>field with an adjacent button (text: "...") that allows lookup of
>values in the edit field.  This allows the user to enter the value
>directly if they know it, or to click on the "..." button to perform
>a search.  (This presumes that there are too many choices for a
>select field to make sense.)

Assume the user starts on screen A, and clicks the search button that takes 
them to screen B which displays a search form. The user fills out the 
search form, clicks OK, and is presented with screen C, which displays the 
search results.  The user then selects from among the search results by 
clicking an href link or a form button.  The user is then returned to 
screen A with the original screen A form data and the search results filled 
in.

Question:  I'm wondering how you move the user to the appropriate screens, 
given your approach described below.

The transition from screens A to B is easy.  This can be hard-coded in the 
struts-config.xml ActionMappings.  How do you determine the transitions for 
the other screens, though?

When the user is presented with screen B, he fills out the search form and 
selects either:

- OK:  we process the search request and transition to screen C if search 
is successful, and return to screen B with errors if search is unsuccessful.
- Cancel:  we obtain the data from the cache, set things up, and return the 
user to screen A
- Hits the browser back button:  ??

When the user is presented with screen C, he either:

- Selects a choice from the search results:  we obtain the data from the 
cache, set things up, and return the user to screen A
- Hits the browser back button:  ??

So this leaves me with a couple of questions:

1. How do we differentiate the transitions when processing the OK or Cancel 
from screen B?  The OK transition to screen C can be specified in the 
ActionMappings in struts-config.xml, but the Cancel request must obtain the 
information from the cache. I suppose this means the token used to store 
screen A's information is written to screen B's form, and retrieved IFF the 
user decides to Cancel screen B's action. True?

2. What happens when the user selects a search result choice on screen 
C?  We want to return the user to screen A.  Does this mean that screen C 
should also be implemented as a HTML form, and that we also write the token 
for screen A to this form?  How do you know which token to write onto 
screen C's form?  Do you just "know" that screen B needs to create a new 
cache entry, and that screen C needs to use the cache entry token that is 
submitted with screen B's request, and therefore code it that way?  Or do 
you have some other mechanism that you've designed?

more below...


>I want to be able to perform the search and return to this screen
>with both the existing data and the search results filled in.  I
>want the user to be able to do this in multiple browser windows
>without them interfering with each other.  I want the "back" button
>to work as expected, because I know that as a user, I get very
>annoyed with the inability to use this button.

When the back button is pressed, doesn't the previous page's request just 
get resent? What are the implications of this...any special processing 
required?


>When the user clicks the "..." search, the entire calling state,
>including the ActionForm bean, is copied into a cache which is
>stored on a per-user basis.

Can you share your code showing how you obtain all of the calling state? 
Also, your cache code, as well, if possible...thanks.

> From the cache, I get a unique token to
>refer to the calling state.  This token is then stored in a hidden
>"caller" element on the new form.  If the user moves forward from
>this screen by pressing either "OK" or "Cancel",

By "moves forward", do you mean possibly moving up the stack of screens, 
e.g. from screen C to screen A?

>the original form
>is restored from the cached information, the cached value becomes
>eligible for destruction, and after a short grace period, the form
>is removed from the cache.

Why do you have this short grace period?  Is this cached information still 
relevant?  Perhaps if the user hits forward and back again on the browser? 
Or something else?  I'm very unclear on how you would access this cached 
information.  For example, if we cache screen A's request information and 
then when we return the user to screen A after a successful search, we 
obtain that cached information (via the token stored on screen C), how will 
we know that cached information exists?  I would have thought that the 
token (which should have disappeared after we processed screen C's request) 
was the only way to get the cached information from screen A's request.

>If the user presses the "Back" button,
>the form remains in the cache longer, although it, too, will
>eventually time out and be destroyed.

Huh?


>In any event, once the user's session is terminated, any saved forms
>are destroyed.
>
>This approach works very well for me.  A stack is implicitly defined
>by the succession of "caller" elements without having to maintain
>anything that looks like a stack on a global level.  I don't know
>how well this approach scales, but short of keeping all of the state
>information in the user's browser, I can't think of any way to
>reduce its footprint.

This all sounds very interesting, and clearly the functionality is 
necessary.  I'd like to implement this in a consistent, architected 
fashion, and appreciate any further guidance you can give.


Rick Horowitz


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com