On Fri, January 6, 2006 2:59 pm, Dakota Jack said: > Heh, Frank, > > The major problem with action forms is that there is an assumption that an > action must be sandwiched between two instances of the same action form > response object. This is simply contrary to what anyone would logically > expect of a normal transversal by a client through a site. An action, > typically, should yield a distinct action form from the prior action form. > > AF1 (response) --> request --> A1 --> AF2 (response).
I would tend to agree with that... you know, I have an interesting experience... almost three years ago I wrote a rather complex application that was not Struts-based, it used a home-grown framework. There was no notion of an ActionForm in it, or anything like it. As a result, the Actions have a method that pulls parameters out of request and stuffs them into a WorkContext object (which looks a lot like a cross between an ActionForm and a ChainContext). Almost two years ago, I was asked to convert the application to Struts. For a number of reasons, ActionForms wound up being used as (a) output containers, i.e., a place to store data destined for display and (b) as storage objects during a wizard flow. I did not use the Struts taglibs, and ActionForms were not attached to Action mappings, hence no auto-population occurred, no auto-validation, etc. Now, it is true that I didn't get much of the benefit of Struts doing this, but it was necassery to avoid rearchitecting the entire application. More importantly though, all the problems typically sited with Struts, and ActionForms in particular, were not present. I had a very easy time of making it do exactly what I want, and this thing is a pretty complex app, has a number of wizard flow, freeform navigation, is what most would now call an RIA, etc. To me, it's really the auto-population mechanism that causes problems, not because I think its a bad idea (it's not) but because I think we don't have enough control over it. I'd like to be able to turn it off on a per-mapping basis for instance, especially when I'm pulling the form out of session and I don't want to just automagically have what's there overwritten with what was submitted (which is, I believe, a problem Michael was pointing out). The interesting thing is, there are some relatively minor tweaks that could be done to Struts that would solve a lot of problems. How about creating Actions per-request? Not at all a significant enhancement, but think of all the things you could then do. How about a simple flag to tell the RP to populate the Action rather than an ActionForm, thereby giving Michael his dream of a combined Action and ActionForm? Again, we're not talking about a big change. These are also not new ideas by any stretch, I, and you, and Michael and others have been tossing these things around for at least a year or more. ...all of which raises a question that I don't know the answer to... does Struts 1.3 pool Commands? I.e., if I implement my Actions as Commands, do I get that per-request functionality I want? If so, that is at least a step in a good direction. > This has been, in my opinion, the biggest downfall of Struts. As you > suggested, Frank, the whole way the view state is taken care of by Struts > is > poor. Woah, hold on now, don't put words in my mouth :) I wouldn't go so far as to say it's poor because many people have had a great deal of success with it. I *do* think there are some shortcomings that may or may not have some relatively simple solutions, and I don't think too many people would disagree. No one thinks Struts is perfect, but based on how many people use it and use it successfully, it's probably not fair to say it's poor, or that any one part of it is poor. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
