According to your logic, Ted, we should not do setups for forms? I really don't understand your point at all.
Jack <SNIP> On Thu, 17 Mar 2005 10:09:03 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > People have often brought up things like multiple ActionsForms up on > the user list, but it seems like a misuse of the ActionForm to me. > > An ActionForm is best used to represent the input needed to service a request. </SNIP> Why cannot an ActionForm with equal validity represent the output needed to service a response? I don't understand your point at all. <SNIP> > Ideally, an Action should be able to take that input and pass it to a > single method on a business facade. Behind the facade, the business > layer might want to disburse that input into a graph of multiple > objects, but that sort of thing should be outside the scope of Struts. </SNIP> This is all well and good, but we still have to service the data needs of the response in setting up pages. <SNIP> > In the Struts 1.x era, some of us started to put other things on > ActionForms besides the input needed to service a request, mainly > because the JavaBeans were a nuisence to maintain. </SNIP> I dont' know what this about and you don't say, so I will have to just ignore the point. <SNIP> > For Struts 1.1 and beyond, a very excellent approach is to use > finely-grained DynaActionForms to represent the input for a particular > form. This can lead to maintaining an attribute in more than one > formbean, but, since it's all in XML, IMHO, the duplication is > trivial. </SNIP> Again, this does not, so far as I can see address the problem that the serverside framework not only has to process values but have to provide setup values. <SNIP> > Without a very compelling use case, I'd tend to be -1 on changing > ActionMappings to support multiple ActionForms. The idea is contrary > to the arcitectural design, just as multiple Actions would be. </SNIP> I really cannot follow you. The basic situation is this: we come from PAGE-A and got to PAGE-B and we need to process the values from PAGE-A and setup values for PAGE-B. In Struts, this presents a real problem because Actions can have access to the ActionForm for PAGE-A and get the values to process or have access to the ActionForm for PAGE-B and provide the values for setup but cannot do both. This means that you EITHER have to use two actions, leading to all the nonsense of chaining actions (why do you think that is recurrent, Ted?), OR you have to make PAGE-A the same as PAGE-B, which you can only do for so long unless you want to emulate Portlets, OR you have to have the same ActionForm for BOTH PAGE-A AND PAGE-B. <SNIP> > Of course, in servicing a request we might need to call multiple > commands and tend to multiple objects, but there's an "M" in MVC. </SNIP> The strange thing is that you have no difficulty with using an Action to setup a form, but just don't want that to be the same action that processes a different form. This is not logical. EIther Actions can be used to setup forms or not. They obviously can be. The question is why cannot they be used FOR THE MOST COMMONS USE CASE to setup a form? Presently, they cannot be used to setup a form in THE MOST COMMON USE CASE, i.e. the case where we go from PAGE-A to PAGE-B and want to process PAGE-A and to setup PAGE-B. This is very strange to me. I don't get your reasoning at all on this one. You prefer to use two Actions to do this? Why? <SNIP> > Though, one scary thing about CoR is that it's going to make it much > easier for people to modify Struts to do things like this. For > example, multiple formbeans could be loaded into a custom > ActionMapping via set-property and then processed by replacing a > Command or two in the Chain. </SNIP> Yes, people will have the freedom to code the way they think best. In this case, I think they are absolutely wrong and am complete bamboozled why you would think otherwise. <SNIP> > It doesn't bother me that people will be able to go off in directions > like these with their own extensions, so long as the cannonical > architecture remains clear. </SNIP> I don't know what "canonical architecture" is. What is it? > On Thu, 17 Mar 2005 06:05:59 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > I note below my biggest WISH for Struts that would be easy to > > accommodate and which would transform the usefulness of Struts, in my > > opinion, in a MAJOR way. > > > > <SNIP> > > On Thu, 17 Mar 2005 06:33:42 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > > > Jack, if you want to throw away ActionForm -- go for > > > it! > > </SNIP> > > > > I have no interest in throwing away ActionForm. I am a huge advocate > > of the use of <html:form> tags. Since you seem to think that this > > somehow is or was a desire of mine, I should say that has never been > > and never will be my desire. Rather, I would prefer if we could make > > ActionMappings such that a single action could result in the > > instantiation of two or more ActionForm objects rather than one. This > > would simply my architecture immensely. This also would be easy to > > do. This would allow coders to be action-centric rather than > > page-centric and still be able to tie ActionForm, as originally > > envisioned, to <html:form>. As things are now, an OOP programmer has > > to use one ActionForm to span two pages. > > > > Jack > > --------------------------------------------------------------------- > 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]
