struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aladin Alaily <>
Subject Re: StrutsCatalogInputOutputSeparation
Date Tue, 10 May 2005 20:21:06 GMT
Hi Paul,

Doesn't putting all of the output data in the session or even in the 
request add even more clutter and confusion?  When the data is nicely 
packaged in an object you can manipulate it more easily and you can keep 
track of where the information came from.  Although using an ActionForm 
for this purpose might confuse some, I think that it is a better 
alternative than putting the data in the session or request scope.


Benedict, Paul C wrote:
> I have read Michael Jouravlev's article:
> I can't find any blog or comment box on the page, so I'll write here. I
> would like people to freely respond to my comments.
> I disagree with the two-actions methodology to solve the separation of input
> and output data. If Actions are a web-interface into your business logic,
> there is no need to go into another action to do more processing; I believe
> the chains approach in Struts 1.3 solves this problem by keeping chains of
> logic below the Web/Struts layer. 
> This technique is known as ActionChaining and, as I agree, it seems to be
> frowned upon:
> I personally do not like putting any output data in the form unless it
> started as input. I envision ActionForms to be tightly linked to HTML forms.
> Conceptually speaking, since HTML forms can only contain input-like
> elements, so should only ActionForm objects too. I put my output data
> exclusively in request or session attributes as necessary, but never the
> form; I believe this complicates and misuses the conception of a form.
> I am ready to be disagreed with... But I want to know why.
> Thanks,
> Paul
> ------------------------------------------------------------------------------
> Notice:  This e-mail message, together with any attachments, contains information of
Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or
its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp
& Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted
and/or legally privileged. It is intended solely for the use of the individual or entity named
on this message.  If you are not the intended recipient, and have received this message in
error, please notify us immediately by reply e-mail and then delete it from your system.
> ------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message