DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14716>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14716

Add a method putToken() to Action class

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From [EMAIL PROTECTED]  2002-11-21 13:49 -------
Andrew, the use case you describe doesn't make sense.  

Consider the scenario:

      #1              #2                  #5             #6
 /viewBook.do -> details.jsp   -> /purchase.do   ->  cart.jsp
                      |
                      |      #3              #4
                      `-> /viewBook.do  ->  details.jsp



 (User is browsing catalog of book titles, clicks on a book)
1. -Action saves token in session
2. -token added in the form
   -User enters quantity "1" to purchase book
 (User sees link to another book by same author)
3. -User clicks to see detail of that book
   -Action saves token in session
4. -token added in the form
 (User decides not to purchase that book)
 (User hits back button, page #2 is redisplayed)
5. -submits form to purchase book
6. -user sees their current items in cart

Here is the link on #2
 <a href="/app/viewBook.do?bookId=548&view=printView">Preview</a>

And here is the submit from #2 to #5
  <form name="form" 
        action="/app/purchase.do?bookId=37" 
        method="GET">


>From what you are describing, how does the framework know what the 
difference is between #3 and #5?

That would be entirely up to you to decide, not the framework.  In fact, 
how are you planning to know the diffence between #1 and #3?

You want to enforce a workflow and prevent duplicate submissions, 
but allow them to leave the workflow with the chance to hit 'back 
button' to get back to the spot they were in before leaving.

The 'what if' scenarios cause by such a use case cause more headaches 
than its worth.

In the future, please consider discussing this on the users list before 
submitting enhancement requests.

We will do our best to help resolve these issues, but Bugzilla is not 
the place for it.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to