I believe the use case is not about going from A to B. It's about going to A
and then submitting data from A. The design of Struts 1.x encourages us to use
one mapping to display a form and another to submit a form. (There may or may
not be more than Action class behind the mappings. I've written many
application that use one Action class and lots and lots of mappings.) The
design of JSF and ASPX encourage you to use one mapping for both display and
submit. Those frameworks are designed around the notion of a "postback" state.
If it's not a postback, you can initialize the controls and skip to the
response. If it is a postback, then the validation and update phases fire.
Moreover, since the controls can maintain their own state, you don't have to
repopulate them yourself on a postback where validation fails. As a result,
there are fewer mappings to write (which leads to fewer mappings to debug).
-T.
On Wed, 05 Jan 2005 14:43:16 -0800, Dakota Jack wrote:
> Thanks, Ted. I would not have guessed this was the focus without
> you having said so. Let me ask a further question, to get a better
> understanding of what this is about. I still am not clear, and I
> hope to explain why in what follows. I really am just trying to
> get a grasp on what the problem is supposed to be as I said at the
> start of this thread. I would appreciate it greatly if you could
> hang in there a bit on this one with me. I like your clarity on
> these things.
>
> When I use an action to go from A.jsp to B.jsp, I have to validate,
> etc. for A.jsp and to setup for B.jsp. This, in itself, is not a
> problem and cannot be what you are talking about, I believe. (If
> it is, please tell me.) If I want to use the same action going
> from C.jsp to D.jsp, then I have the same thing, but a different
> mapping. This too cannot be the problem. (If it is, again, please
> tell me.)
>
> Maybe I have just provided myself with a solution, which we all
> must do that does not seem like a "kludge" to me or something. On
> pages, I use constants to get information from a map on a form,
> such as DATA_1, DATA_2, etc., and also constants for
> logical/operational information, such as LOGIC_1, LOGIC_2, etc.
> So, my pages have lots of things like including
> "...='${whateverForm.map.LOGIC_1}'",
> "...='${whateverForm.map.DATA_1)'", etc. and most actions include
> at the start "whateverForm.clear()". You get the idea.
>
> There are lots of things that I see we could do with Struts and
> most of them, if not all of them, have been discussed on the list.
> But this one has me mesmerized or confused. Am I just missing the
> point or what? How could the setup and processing logic end up in
> two different actions? Or, why would anyone chain actions when
> they can chain the way something is handled inside a single action?
> I am just not seeing this. I am not saying there is nothing to
> see.
>
> Jack
>
>
> On Wed, 5 Jan 2005 13:21:26 -0500, Ted Husted <[EMAIL PROTECTED]>
> wrote:
>
>> 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: dev-
>>>>[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: dev-
>>>[EMAIL PROTECTED] For additional commands, e-mail:
>>>[EMAIL PROTECTED]
>>
>>
>> ------------------------------------------------------------------
>> --- 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]
