In practice, a rich page will require a lot of setup. For example, it's not uncommon for page to have several select boxes that need to be populated. When you prepare to setup the page, you might also need to look up a domain record, as well as a user profile, and so forth.
After it's displayed, and the form is submitted, and found to be valid, the rest of the logic is very different. We don't have to populate the form any more, we just have to process the result. The result may mean updating a database or doing something else entirely. There are workarounds and kludges, but in classic Struts 1.x, validation is a yes/no setting for each mapping and there is also one validation method per mapping. When you are setting up the page, you don't want to validate the input (or want to validate it differently). When you are processing the page, you do want to validate the input. Hence, a cannonical need for multiple mappings. (Again, there are tricks you can plan, but this is not where we discuss tricks, it's where we discuss changes that obviate tricks.) In JSF and ASPX, this problem is addressed with a "postback" state. The framework determines whether the page is being displayed or redisplayed, and the backing bean (or code-behind) can act differently for each state. Meanwhile, no one is proposing any revolutionary changes to the Struts 1.x architecture. We are discussing a number of evolutionary changes, most of which have been reduced to the roadmap, and all of which will be backwardly compatible with the prior 1.x release. No matter what happens with Struts 2.x, work will continue on Struts 1.x. At least, so long as there are volunteers ready, willing, and able to do the work. In a volunteer environment, Darwin always decides. The better technology attracts the best volunteers. Better volunteers do better work, and the spiral continues upward. Which is better? I don't know. Neither do you, or Joe, or Craig. It's not up to any one person. It's up to the community of volunteers who do the work, both here and on the user list. -Ted. On Wed, 05 Jan 2005 07:15:54 -0800, Dakota Jack wrote: > I realize it was an answer, Jan. My question, however, is whether > there is a problem when someone does not chain actions and whether > there is not a way to avoid doubling actions or whether there is a > real problem. Is that unreasonable? Or, are we just supposed to > assume there is some imagined problem at the root of needing to > change an entire archetecture? > > Jack > > > On Wed, 5 Jan 2005 07:32:56 -0000, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > >> Dakota, >> >>> -----Original Message----- >>> From: Dakota Jack [mailto:[EMAIL PROTECTED] >>> Sent: dinsdag 4 januari 2005 18:29 >>> To: Struts Developers List >>> Subject: Re: Coupling, Struts and JSF >>> >>> Hi, Jan, >>> >>> I am less interested in how people make mistakes but rather in >>> what the problem is for people that don't chain actions. >>> >> >> It was an answer to your question: >> >> <snip> >> >>> In the wiki, you say "[y]et in Struts 1.x, for example, the >>> setup >>> >> logic >>> and processing logic end up in two different Actions, requiring >>> multiple action mappings". Could you expand on this a bit >>> >> >> </snip> >> >> But I did expect this kind of reply. >> >>> Jack >>> >> Regards, Jan >> >> ------------------------------------------------------------------ >> --- 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~ > > "You can't wake a person who is pretending to be asleep." > > ~Native Proverb~ > > "Each man is good in His sight. It is not necessary for eagles to > be crows." > > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ > > ----------------------------------------------- > > "This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive > this for the addressee, you must not use, copy, disclose, or take > any action based on this message or any information herein. If you > have received this message in error, please advise the sender > immediately by reply e-mail and delete this message. Thank you for > your cooperation." > > -------------------------------------------------------------------- > - 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]
