There are a "jillion" solutions, of course. I still think, and maybe I am stating it too much, that the solution should be framework and definitely should not be in a session object. I do think that application data should be handled and have suggested a StrutsState application in application scope. But, the screen data should be handled, I think, by a screen application of ActionForm or like VOs. I would separate validation from ActionForm, etc.
On Fri, 18 Mar 2005 10:32:35 -0500, Rick Reumann <[EMAIL PROTECTED]> wrote: > Frank W. Zammetti wrote the following on 3/17/2005 10:23 PM: > > > Certainly I can see the reasoning behind that, but I would have to > > disagree. What if down the road I need to use one of those screens > > independant of that original flow? Isn't it just added complexity to > > have all the extra stuff in the ActionForm then? > > Ok, then how about using separate ActionForms and after each submits > copy the properties (BeanUtils) to a POJO that you are using in Session > scope to hold the values you finally need. This way you have the > flexible separate ActionForms but still have a Master record holding > what you need along each step. (Heck, you could even take the lazy way > out and make the master session object a Map so you wouldn't even have > to care about creating the pojo ahead of time.. although I still prefer > a nice POJO over a Map for stuff like this.) > > > A good example is the application I was talking about itself... The six > > screens are not simple in and of themselves, there is quite a bit of > > complexity to the ActionForms for each, in terms of how many fields > > there certainy. If I combined them all it would be a very unwieldly > > beast to maintain (I'd have to look, but I can imagine it being close to > > 2,000 line of code without much trouble, perhaps more). > > Well, remember those 2000 lines of code are simply getters and setters > which are easily auto-generated. It's not really complex lines of code. > Really you are only maintaining field names. I do see your point though > about how it's nice having the ActionForms separate for a more resuable > approach. I'd opt for the option I mentioned above first, if you want to > keep the forms all separate. > > > In addition, how would you handle validation then? The validate() > > method is meant to apply to a single page (as is an ActionForm), > > Actually you can validate on an action mapping basis and not on the form > name, so only the fields you are interested in for the action mapping > get checked. > > -- > Rick > > --------------------------------------------------------------------- > 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]
