Rick,

I also found this thread interesting, and I am keen to keep the discussion
alive with the end result being, if not more support for this sort of thing
in Struts, then a standard design pattern for implementation on top of
Struts. An example in code would be really nice :-), although I'm happy to
help out in that regard.

Here's my 2c...

> 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.

I would also add, that there might be a great many screens that want to
launch screen B (lets call them screens X, Y and Z) to search for a
particular entity type, and that having selected one of the search results
on screen C, the user should be returned to screen X, Y or Z as appropriate
(with the new data, plus original data, filled out).

> - Hits the browser back button:  ??
In all cases the browser back button is going to go back to the previous
screen without further server interaction isn't it, regardless of the cache
settings of that page.

> 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?
Wouldn't we just let the user use the back button in this case? Won't the
browser populate the HTML fields with their values prior to the A->B link
being clicked (although, possibly not the case with password fields and
file fields???)

> 2. What happens when the user selects a search result choice on screen
> C?  We want to return the user to screen A.
But the fact that it's screen A should not be hard-coded! Because it might
be screen X, Y or Z that we actually want to return to, depending on where
screen B was invoked from.


>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?
I believe the browser simply retrieves the page from its cache, but this
probably differs from browser to browser. As an example, check out this
link ( http://support.microsoft.com/support/kb/articles/Q234/0/67.asp ) for
an overview of what MSIE does. The interesting bit is:

"However, the page (that has been marked with the HTTP 'Expires' header
equal to -1) remains in the disk cache and is used in appropriate
situations without contacting the remote Web server, such as when the BACK
and FORWARD buttons are used to access the navigation history or when the
browser is in offline mode".

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

I too wouldn't mind see this from the original poster if they are able to
share it!

Regards,
James W.

--------------------------------------------------------------------------
This e-mail is from Cards Etc Pty Ltd (ACN: 069 533 302). It may contain
privileged and confidential information. It is intended for the named
recipient(s) only. If you are not an intended recipient, please notify us
immediately by reply e-mail or by phone on +61 2 9212 7773 & delete this
e-mail from your system.
--------------------------------------------------------------------------


Reply via email to