That's it! Frank nails it again! ///;-)
On Thu, 17 Mar 2005 18:35:52 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Let me try and explain... > > Let's say I have a wizard-like interface to my site... One the first > page I enter some values, let's say First Name, Last Name and Social > Security Number. I click Next. > > Now, the next page that will be shown will prompt me to enter an address > for the person I just entered. It's really independant of what I did on > the first page (I'm just collecting information until, presumably, some > save process at the end occurs). Let's say one of the fields is a > dropdown of countries. I don't want to hardcode this into my page, and > rightly you would agree I think :) So, I need some server process to > read from a database maybe and return the values for the dropdown. > > Now, what happens when we click Next from the first page? The usual... > an ActionForm is instantiated and populated and sent to some Action. I > do whatever it is I do there, and I return a forward to send me to the > second page. > > Here's where the problem comes in... At what point in this process do I > get that list of values for the country dropdown on the second page? > > There are plenty of alternatives... > > * I could read from the database in the first Action (delegate to some > business class hopefully!) and stick it directly in Request. But that > breaks isolation between the pages. The Action associated with one page > should not set up for another. > > * I could "chain" Actions, i.e., forward to an Action instead of > immediately to the second pages' JSP, that is specifically designed to > get the values for that dropdown. Aside from the overhead of the extra > pass through the entire framework, it's a kludge anyway. > > * I could instantiate the second "setup" Action at the end of the first > Actions' execute(), and call the seconds' execute() manually, which > presumably gets the list and sticks it in request. I've used this > solution the most myself, but it too suffers from the lack of isolation > between Actions. > > * I suppose you could read the values from the database in the JSP, but > you'd be shot on sight and I'd be the one yelling FIRE! :) > > * You could use my setupItems. But, that is something you have to do > yourself and it will almost certainly result in an incompatibility with > future versions of Struts. > > There are I'm sure other answers too. > > But all of them, well, not my setupItems! :) are ugly hacks. > > I have to agree with Jack that this is a very common use case (the most > common? That might be debatable, but certainly very common). > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Rick Reumann wrote: > > Dakota Jack wrote the following on 3/17/2005 4:20 PM: > > > >> I am with Joe on this one. This situation is, at least for me, the > >> most common situation I face. Every page except the welcome page has > >> input for me. > > > > > > Sorry, I'm not bringing this to the dev list because I'm first just > > trying to understand what exactly is the 'common situation'. I don't > > think your wiki post explains the problem very well (granted I'm dense, > > so bare with me.) The wiki states: > > > > "The most common use case that I know of is when we go from one page to > > another page on the browser, sending the server certain request values > > from the first page and getting from the server certain response values > > on the second page. Most pages have both input data (setup) and output > > data (request name/value pairs). > > > > I presume that we are using Struts, so the first page and the second > > page will each have different <html:form> values." > > > > > > If I'm understanding you correctly, the only time I find the above is > > slighlty problematic is when what needs to be populated on "Page 2" is > > directly dictated by what was submited on "Page 1." If this is the > > case, I certainly wouldn't say that is the most common problem in > > relation to form submits. > > > > I tend to think the order of most common scenarios (in relation to form > > submits) would be... > > > > 1) User submits a form. Result page needs to display some sort of > > results based on the form info submitted. This could be a simple > > cofirmation message or maybe a results page with a list of employees, > > car types, or some financial results. Typically this page is also > > interactive in the sense you could often click on an employee or car > > name to get more info. [I'd hopefully be correct in assuming this first > > scenario is unaffected by the problem you are proposing?] > > > > 2) User submits form. After processing the data, the user needs to be > > brought to another form where he/she will enter in more information. > > This scenario falls into three basic types in how the two forms are > > related... > > > > o A) Form 2 (page 2) does not need to be prepopulated with anything > > special. The simple default values in the ActionForm backing the page > > are good enough. > > - in this case after form 1 submits it's as simple as doing a > > typical forward to the jsp holding form 2 > > > > o B) Page 2 needs to have some prepopulation take place. > > - This is a case for when I think forwarding to another Action is > > just fine. So when form1 submitted, my "success" foward would simply > > equate to the Action mapping needed for page 2: > > > > <forward name="success" path="/carStuff.do?dispatch=setUp"/> > > > > o C) The form on Page 2 needs to be populated with data that is > > DEPENDENT on what the user submited on the form on page 1. [I believe > > this is the case you and Joe are most concerned with?] The problem is > > that you now need to create an instance of the ActionForm that you need > > on page 2 and populate it in the Action that form 1 submits to OR, what > > I'd probably do, is... after I'm done processing what I need in my first > > Action, I'd stuff the values that I needed in the next action back into > > the request and foward to my next action like in step B above. Of course > > I might have a different dispatch method for this for when I know I'd be > > coming from this type of scenario. Maybe something like processFromXXX > > or something like that. I think the difference in the approaches is that > > you'd want to leave the 1st Action and go right to the next page (with a > > new form) whereas I think it's more clean to foward to the approriate > > action to take care of any prepopulation (even if based on params from > > an earlier request). With this later approach you don't need to worry > > aobut creating the correct ActionForm instance. > > > > > > *I guess my question is what scenario are you guys mentioning that is > > common for the cause of this concern? I'm guessing it is step 2.C above? > > With the preponderance of possible struts questions that come along this > > certainly is not 'that' common. I don't see that many applications where > > every page is a form and each form's population of fields is that > > intricately tied to what was submitted on the previous form. (Exception > > of course is wizard based applications - like steps to filling out > > online taxes, which in that case, I think one ActionForm across requests > > is the cleanest approach). > > > > I'm not trying to be a pain, but I'm sure I'm not the only one that is > > slightly confused by the problem statement that you are posing on the > > wiki page. > > > > > > > > > > And, I have to redirect the welcome page because I need > > > >> data there too. I bet if you looked at the posts to the users list > >> seriatim you would find that a very surprising percentage of posts > >> would center on this problem. I know that it can be solved > >> programmatically, Rick, but think that this is something the framework > >> should do. > >> > >> I agree that ActionForms should be associated with page forms. That > >> is why I think this should happen. > >> > >> Jack > >> > >> http://wiki.apache.org/struts/StrutsMultipleActionForms > >> > >> > >> On Thu, 17 Mar 2005 15:05:28 -0600, Joe Germuska <[EMAIL PROTECTED]> > >> wrote: > >> > >>> I find this a quite common experience, and I just posted a response > >>> to Jack on the dev list outlining the direction I intend to take to > >>> provide a solution. Also, as noted on the dev list, now that Struts > >>> 1.3 allows you to easily configure arbitrary String properties on > >>> ActionMapping (ActionConfig) means that it should be relatively > >>> straightforward to add properties like "responseform.name" and > >>> "responseform.scope" and do whatever you want with them. > >>> > >>> I'm afraid that in the current Struts model, there are still quite a > >>> few things to juggle to get an ActionForm instance. At the bare > >>> minimum, you need an HttpServletRequest (and from it, a ModuleConfig > >>> and possibly the session) and two Strings. > >>> > >>> I think it would be nice to make it very clear how to get an instance > >>> with out having to juggle all of these. It would be possible, for > >>> instance, to add a method to ActionContext (which encapsulates the > >>> request scope, the session scope, and the module config) which would > >>> take two String arguments and return an ActionForm. I think some > >>> would object to putting that much behavior in ActionContext, so an > >>> alternative would be to pick a Utils class (or maybe the > >>> ModuleConfig) and pass it the ActionContext and two strings. > >>> > >>> If you're interested in the issue, though, let's continue the > >>> discussion on "dev" (thread subject: "ActionConfig property map and > >>> form setup strategies (Re: POJO Actions and the ActionCommand > >>> interface)") > >>> > >>> Joe > >>> > >>> At 2:50 PM -0500 3/17/05, Rick Reumann wrote: > >>> > >>>> Rick Reumann wrote the following on 3/17/2005 2:29 PM: > >>>> > >>>> > >>>>> Convincing me that 'more' ActionForms are a good thing is going to > >>>>> be a difficult task, but restate or post your summary propostion > >>>>> and I'll 'attempt' to look at it without any preconceived notions > >>>>> that you might be crazy:) > >>>> > >>>> > >>>> Jack, I saw your post here on the dev list, and I believe I know the > >>>> problem you are talking about. Yes, I have run into the annoying > >>>> situation where you have a new form you need to set for the > >>>> resulting page you will be forwarded to. I'd argue though that this > >>>> isn't "that" common of occurrence and when it does occur I don't > >>>> find it that big of a deal to just manually instantiate the form > >>>> that I'll need (in the first action) and stuff it into scope so it's > >>>> ready for the ensuing jsp to use. (I could be wrong, though, in > >>>> understanding the situation you are concerned with.) > >>> > >>> > >>> -- > >>> Joe Germuska > >>> [EMAIL PROTECTED] > >>> http://blog.germuska.com > >>> "Narrow minds are weapons made for mass destruction" -The Ex > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
