• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Confused about scope

 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have a problem with a JSP I wrote using Struts. The JSP is a protocol search page offering three uses cases in a single Struts action: searching, deleting, downloading. When the user presses the buttons for downloading and deleting appropriate form fields are filled by a JavaScript function to determine which protocol to download or to delete. These fields are called protocolId and downloadId; the search (submit) button doesn't use JavaScript.

My problem is that after the user chose to download a protocol (the browser opens a download dialo etc...) and then hits the search button the protocolId or downloadId fields are still set (-> no empty string). This is troublesome because I use the state of protocolId and downloadId to determine what the user did within the action. Like:



So the result is that a download window pops up after the user once chose to download a file and then hits the search button. What puzzles me is that I'd expect the form valid for the current request only, but apparently the IDs are still around. What do I miss here? Do I have to write a reset method in form class?

My Struts configuration:
 
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suspect this problem has less to do with the scope of the ActionForm, and more to do with the way you're submitting your form. From what you've told us, it sounds like a user could press the download button, start filling out the form with a protocolIdDownload, and then change his mind and press the search button instead of the download button. This would mean that the protocolIdDownload field value has been set on the client side prior to submitting the form.

If I have understood the problem correctly, it could be solved by adding some JavaScript to your submit button to make sure the other fields were cleared. Example:
 
Mike Himstead
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To clarify my previous post: the user doesn't enter download or delete IDs. These IDs are passed by URL parameters, so whenever a user hits the download button, the ID is passed to the form by JavaScript and submitted. The downloadId is still there at the next submit.
 
Merrill Higginson
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mike Himstead:
These IDs are passed by URL parameters


That's why they are persisting. Even if the ActionForm is in request scope, Struts looks at the parameters passed in the URI in each new request and calls the appropriate setters on your ActionForm.

One solution might be to have your Action class set the value to null or null string after each operation has been executed.
 
Mike Himstead
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wouldn't implementing the form's reset method be sufficient?

Merrill, thank you for your help and effort. I really appreciate it.
 
Merrill Higginson
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mike Himstead:
Wouldn't implementing the form's reset method be sufficient?


No, it wouldn't because Struts calls the setters on your form after it calls reset. Therefore, the fields would still be populated.
 
Mike Himstead
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mmh, it seems I need to improve my knowledge about Struts and the general submit procedure. If I do something like

myForm.setDownloadId("");

at the end of my action class, what keeps Struts from repopulating that piece of data with the URL parameter's value (AFTER the next submit BEFORE the action's execute method)? This value is still around if I got you, right?
 
Merrill Higginson
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's an example scenario. In this scenario, I'm assuming that protocol.jsp has an input field for protocolIdDownload, either displayed or hidden (hmtl:input or html:hidden tags).

1- User selectd download, populates protocolIdDownload with "123" and submits some URL with ?protocolIdDownload=123.

2- Struts calls the reset method, then reads the paramaeter and calls setProtocolIdDownload("123").

3- The execute method of the action class is called, it does the download and forwards to protocol.jsp.

4- Since protocol.jsp has an <html:hidden> or <html:input> tag with a property name of protocolIdDownload, the value that gets rendered in the JSP is "123". It takes as its value whatever is in the protocolIdDownload property of the form bean, which is still "123"

5- The user selects the search button and submits the form. Even though this time he didn't explicitly populate protocolIdDownload, it's still "123" because of the value attribute set implicitly by Struts in the JSP.

6- Struts calls reset, reads the parameter and calls setProtocolIdDownload("123").

7- The execute method of your action class is called, and the protocolIdDownload property is still "123".

If you set protocolIdDownload to null after performing the download in step 3 above, it will be null thereafter and your problem is solved. Another way to solve the problem would be to specify value="" in the input tags.
 
Mike Himstead
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just tried to set the appropriate ID to NULL or empty String, but the problem remains. The IDs are still there after the next submit. I think I nailed the problem down to the fact that for downloading a file I return NULL thus bypassing Struts. I do empty the ID strings, but I guess that this is irrelevant then.
[ November 22, 2007: Message edited by: Mike Himstead ]
 
Ranch Hand
Posts: 948
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Reading through this I agree with Merrill's assessment of the problem. The problem really has nothing to do with Struts. It sounds like you are setting a hidden field on your form when the user clicks the Download button. Unless you clear that value it will still be set when the form is submitted when the user clicks the Search button.

If the page reloads after clicking the download button you can define your html:hidden tag so it sets the value to empty...like this:
<html:hidden property="downloadId" value="" />

If the page does not refresh then you can use JavaScript to clear the value when the user clicks the Search button or in the code that is executed when the user clicks the Download button.

Posting your JavaScript code would help.

- Brent
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic