For the following discussion, please keep in mind I'm speaking of a page that displays read-only (yet dynamic) text, or a page that is a *response* to a form submission, which itself contains some dynamic (read only) data.
In most (all?) tutorials I've seen on struts, they typically have something like this:
And then the JSP makes use of that request attribute through the struts taglibs.
But... in most of the code here at work, I find that they are 're-using' the ActionForm being passed in, and using that in the response. By just doing this:
So, I note that there is apparently no need to 'set' the form in the request. Because we're forwarding to the eventual view, right?
Is that "ok"? I mean it obviously is.. it's working here. But is it 'normal'? [ April 24, 2008: Message edited by: Mike Fourier ]
The example you show is pretty standard for cases where you want to use request scope on your actions.
You need to use session scope to take advantage of the same values set in the formbean. This has the advantage of simplifying the use of data, but makes it more complex to "clean" things when data needs to change.
Which is more appropriate to use depends on the needs of each specific form, etc. I use both in my Struts applications, as needed.
There will always be people who are ahead of the curve, and people who are behind the curve. But knowledge moves the curve. --Bill James
In Struts, as you know, each Action has a form bean associated with it. When a form is submitted, Struts automatically instantiates the form bean associated with the action declared in the JSP, puts it in scope (Usually request) and populates its properties. If the action in turn forwards to a JSP page, the form bean is still in scope, so the JSP page can display fields in the form bean with bean:write. However, if the JSP is not display only, it's action must use the same form bean as the action that forwarded to it in order to populate html:text fields from the form bean.
So, in answer to your question, it's perfectly normal not to put the form bean in the request, because Struts has already done it for you. [ April 24, 2008: Message edited by: Merrill Higginson ]
Stevi: thanks, but my question wasn't about request vs. session. I have seen tutorial code that talks about "cleaning up" your session objects, after you're done with them. I've also seen how one *needs* to put some stuff in session, if you're doing validation. The example I saw was "look, if struts calls .validate() and fails, and directs you back to the start, it doesn't run through the action again, and so now what will your drop-downs contain? Put those in the session, and then remember to remove them when you're done." I might be mis-remembering a bit of that, or getting it slightly confused, but I'm crystal clear on what the request and session buckets are (and what they're for).
Merrill: whoops.. I see what I did there, sorry.
I wasn't asking if it was normal to not explicitly set the ActionForm back into the request. I get that it's because we're (well, Struts is) doing a requestdispatcher.forward(), and so therefore, when struts put the ActionForm in the request before it called the Action, it will still be there after the forward. So right, the view JSP can see it.
I was really wondering about the *re-usage* of the ActionForm in such a manner.
I've been at the web development game a long time (nearly a decade), but remarkably, have avoided struts for all that time. So seeing all the tutorials so far make use of the ActionForm as a sort of "here, we'll use this to carry the request parameters from your HTML form into the Struts Action class", and to see that be its *only* use in examples and tutorials.
And to see how tutorials/examples tend to then explicitely set *different* objects containing results and/or view data into the request and forward on to the subsequent views...
It then seemed really odd to me to see production code that "blithely" re-used something I had been self-taught to think of as "the thing that gets data in" be re-used as "the thing that gets the data out".
So my original question still stands: Is it 'normal' to use the ActionForm for both 'in' and 'out'?
> However, if the JSP is not display only, it's action must use the same > form bean as the action that forwarded to it in order to populate > html:text fields from the form bean.
I'm thinking that scenario would be a form that collects data, and if/when you discover you want to go back to that form, to collect more/different data, then yes, the ActionForm must be sent back as well.
PageA -> ActionA (populates ActionFormA) -> Forward 'back' to PageA for some reason (so ActionFormA needs to still be there)
My scenario is more like:
PageX -> ActionX (populates ActionFormX) -> Forward 'on' to PageY (and use the ActionFormX instance to display stuff).
Does *that* make sense?
What about this scenario:
Page?? (Actually, a link. Page (form) doesn't really exist, there is no submitted data) -> ActionQ (query for non-request-specific data and display it) -> Forward to PageQ
In this scenario, I don't really even *need* an ActionForm, right? No inbound data at all. So now, I *need* to make up my own view object, I don't have an ActionForm to re-use.