struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: Coupling, Struts and JSF
Date Wed, 05 Jan 2005 22:43:16 GMT
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 <husted@apache.org> 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, JAN.Cumps@intl.pepsico.com
> > <JAN.Cumps@intl.pepsico.com> wrote:
> >
> >> Dakota,
> >>
> >>> -----Original Message-----
> >>> From: Dakota Jack [mailto:dakota.jack@gmail.com]
> >>> 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-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> > --
> > ------------------------------
> >
> > "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-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 


-- 
------------------------------

"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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message