On 10/05/2005 22:21, "Aladin Alaily" <[EMAIL PROTECTED]> wrote:
> 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.
What about packaging the output data on a java bean and always register it
on a specific name (for example "view") either on the request or session
scope?
In the end you have something like ${view.property} on your jsp file.
It is true that you might not be able to easily use <html:options> but with
JSTL you can reduce this disadvantage.
Pedro Salgado
>
> Aladin
>
>
> Benedict, Paul C wrote:
>> I have read Michael Jouravlev's article:
>> http://wiki.apache.org/struts/StrutsCatalogInputOutputSeparation
>>
>> 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:
>> http://wiki.apache.org/struts/ActionChaining
>>
>> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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]
