On 12/26/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > > >>I would use the Request for such a List and wouldn't even bother putting > it in the ActionForm > > But that of course doesn't make the list persist. Most frameworks heavily > rely on the user session > and I am now a strong believer that's the better way of doing things.
I think it depends on the kind of list and each person may have their own preference. For example, I personally would reather persist on the backend with iBATIS or hibernate vs just stuffing things in the Session. For example, what if it's just one form that needs the list and the user only hits the form one time during the whole time using the site? You've now just just stuff a list in Session scope for what gain? If it's a list that actually will *never* change than put in Application scope. I don't see the point of putting most lists in Session scope. For struts apps most people end up stuffing lists in Session scope so that if validation fails their lists persists on the page. I don't call the validate method manually so I don't run into this problem. Also remember we are talking about "lists" here. Don't think I'm against the Session (if you do a mailing list search you'll see I love the Session maybe too much:) If I remember correctly, I know you promoted a solution of using the > validate() method of > containing those populated lists. That's on the right track but I think a > misuse of the validate() > method. Actually you are remembering incorrectly:) I'm assuming you are referring to this article http://reumann.net/struts/articles/request_lists.jsp, but there I stated exactly the OPPOSITE - that you SHOULD NOT use the validate method for setting up those lists. I said I "do validation manually." I did show how you can simply call the form's validate method manually (even though I don't even go that far in my own apps), but I never mentioned it's a good idea to set up lists in your validate method. Thankfully it's corrected by Struts 2.0/Webwork by a prepare() method that > is called > before executing mostly everything else. JSF is great at handling all of this as well so don't leave JSF out. I try to keep my ActionForm with 'only' properties that the user can edit - > nothing more. > > Ahhhhh! You and I really chatted this up a year ago. I was gung-ho for > this method, but no longer. > I was a very die hard proponent of this but I could only go so far with > it; the problem was it > made no logical sense to contain some data in the form (which was then put > into the request) and > then some data in the request. Both end up in the request, so why separate > the two? It did not > allow me to encapsulate my data --- and it created a very difficult > nightmare to track down which > request attributes were appropriate for a given form. So in response, I > concluded this method was > good up to a point, but everything in the action form suited more complex > cases. Well think about it this way, JSF has it right in that it eliminates the need for an ActionForm. It let's you use your regular Value objects which I think is great (I hate the Struts ActionForm:). JSF gets around the Lists problem, though, by taking a whole different model approach which has been talked about enough on the list here but I do like how JSF handles this. (That being said, there are some things I have found frustrating using JSF(MyFaces) so I'm not ready to jump ship yet.) What > seemed like a good solution back then turned out to be the best at that > time; now I think > everything in the form is a better performing car. I only have one "prep" method in my Action so anything that needs to get setup in a form goes in that one place and can be called from the other dispatch methods in the Action. I like the approach since it is easy to maintain. I don't really see what putting the Lists in your ActionForm gains you? You are still going to have to populate them from method calls to other backend objects. Even then, I would think you'd want to use a prep method for that as well since you might need to prep those lists in your form from several dispatch methods. I'm not so sure how doing... form.setSomeList(list) gains you anything over request.setAttribute(Constants.SOME_LIST, someList ); especially if both types of setting is done from a centralized place in your Action. Then again, I'm of course not saying it's bad or wrong to put the stuff in the ActionForm (I even like approaches where nest your value object in the ActionForm). Overall though, I'm just not a fan of having to be stuck using ActionForms in the first place, so I try to avoid as much dependency on them as possible (I really do like the managed bean approach of JSF which handles this stuff so nicely). -- Rick
