You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Benedict, Paul C" <pa...@merck.com> on 2005/05/10 21:30:47 UTC
StrutsCatalogInputOutputSeparation
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Dave Newton <ne...@pingsite.com>.
James Mitchell wrote:
> I consider myself a reasonably minded person, yet I tend to disagree
> with such assertions that, in my mind, are unreasonable.
Yeah, but I was being sarcastic.
"Look, an argument isn't simply a contradiction [...]"
"Yes it is."
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by James Mitchell <jm...@apache.org>.
I consider myself a reasonably minded person, yet I tend to disagree with
such assertions that, in my mind, are unreasonable.
:P
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
----- Original Message -----
From: "Dave Newton" <ne...@pingsite.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Thursday, May 12, 2005 11:16 AM
Subject: Re: StrutsCatalogInputOutputSeparation
> James Mitchell wrote:
>
>> I disagree.
>
> Wait, trinary logic?
>
> Dave "Is it Friday already?" Newton
>
>>> Ted Husted wrote:
>>>
>>>> Reasonable minds can disagree. :)
>>>
>>> No they can't.
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Dave Newton <ne...@pingsite.com>.
James Mitchell wrote:
> I disagree.
Wait, trinary logic?
Dave "Is it Friday already?" Newton
>> Ted Husted wrote:
>>
>>> Reasonable minds can disagree. :)
>>
>> No they can't.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by James Mitchell <jm...@apache.org>.
I disagree.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
----- Original Message -----
From: "Dave Newton" <ne...@pingsite.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Thursday, May 12, 2005 10:59 AM
Subject: Re: StrutsCatalogInputOutputSeparation
> Ted Husted wrote:
>
>>Reasonable minds can disagree. :)
>>
>>
> No they can't.
>
> Dave
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Dave Newton <ne...@pingsite.com>.
Ted Husted wrote:
>Reasonable minds can disagree. :)
>
>
No they can't.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Ted Husted <te...@gmail.com>.
On 5/10/05, Benedict, Paul C <pa...@merck.com> 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.
Apparently, with Moin Moin you need to add any comments directly to the page.
We should probably get in the habit of adding a
== Comments ==
section to the foot of each page, since we do want the wiki to be a
shared resource.
Of course, because it is a shared resource, it's quite possible that
some wiki articles will contradict each other in some ways. But,
that's OK. Reasonable minds can disagree. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Michael Jouravlev [mailto:jmikus@gmail.com]
> Gesendet: Dienstag, 10. Mai 2005 23:58
> An: Struts Users Mailing List
> Betreff: Re: StrutsCatalogInputOutputSeparation
>
> One more thing:
>
> On 5/10/05, Leon Rosenberg <st...@anotheria.net> wrote:
> > Now seriously. Using ActionForms for result presentation is just a
> > matter of bad style, it doesn't mean, that struts is
> badstyles, after
> > all, everything, that can be misused, will be :-)
>
> So, you are saying that using ActionForm for output is a bad style.
> Depends. Consider this situation (about 80% of this is copied
> from my reply to Nancy Lin):
>
> * There is permanent storage (database)
> * There is business object, which can be loaded from database.
> * There is a temporary area in the session ("current item")
> * "Current item" contains a working copy of persistent
> business object (along with messages, more on them further).
> Current item is the one that you are editing or viewing.
> * There is an action mapping, which does not care, where the
> data that it shows, comes from. All it knows, that when is
> receives object ID, it must show object's data.
> * When [form/action/whoever on that location] receives object
> ID, it checks "current item" first. If "current item" has
> object with needed ID in it, form uses object's properties.
> * If object with needed ID is not loaded in "current item",
> then current item is discarded, object is loaded from
> database into current item and is displayed.
> * When Cancel is clicked, current item is disposed, database
> is not affected.
> * error messages are stored in the "current item" along with
> business object, but messages themselves are not part of
> persistent object.
> * each time page is reloaded, messages are redisplayed
> * when changes are reset or canceled, messages are cleared.
>
> Now, in my older application I use a separate object to store
> "current item". But if one has only one object on the page,
> one can as well use form bean as a "current item". Form bean
> scope would be set to session, and it would store error
> messages, as well as reference to the business object.
>
> Also, as you can see, the action which displayes the item,
> does not accept input of item data. There is a completely
> separate action for that. editItem action does not care where
> the data is, and is it new or existing. It just takes ID and
> pulls the object for presentation.
>
> You may consider this bad style, but I think it is convenient.
Hmm, never seen such an object before :-)
I mean the object must be _completely_ plain, not one field which is
"decorated", only 100% the data, the user entered previously?
I mean, if you would forget about your object sharing, and create an "input"
and an "output" object from scratch, the result would be
100% identical? In this case, and only in this case, the above method would
be "right" (in terms of good coding style, etc),
but in this case I doubt, that you need an object at all. Since you object
is just an encapsulation of properties, without ANY functionality ever,
you'd be better served with a set or map of properties.
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Michael Jouravlev <jm...@gmail.com>.
One more thing:
On 5/10/05, Leon Rosenberg <st...@anotheria.net> wrote:
> Now seriously. Using ActionForms for result presentation is just a matter of
> bad style, it doesn't mean, that struts is badstyles,
> after all, everything, that can be misused, will be :-)
So, you are saying that using ActionForm for output is a bad style.
Depends. Consider this situation (about 80% of this is copied from my
reply to Nancy Lin):
* There is permanent storage (database)
* There is business object, which can be loaded from database.
* There is a temporary area in the session ("current item")
* "Current item" contains a working copy of persistent business object
(along with messages, more on them further). Current item is the one
that you are editing or viewing.
* There is an action mapping, which does not care, where the data that
it shows, comes from. All it knows, that when is receives object ID,
it must show object's data.
* When [form/action/whoever on that location] receives object ID, it
checks "current item" first. If "current item" has object with needed
ID in it, form uses object's properties.
* If object with needed ID is not loaded in "current item", then
current item is discarded, object is loaded from database into current
item and is displayed.
* When Cancel is clicked, current item is disposed, database is not affected.
* error messages are stored in the "current item" along with business
object, but messages themselves are not part of persistent object.
* each time page is reloaded, messages are redisplayed
* when changes are reset or canceled, messages are cleared.
Now, in my older application I use a separate object to store "current
item". But if one has only one object on the page, one can as well use
form bean as a "current item". Form bean scope would be set to
session, and it would store error messages, as well as reference to
the business object.
Also, as you can see, the action which displayes the item, does not
accept input of item data. There is a completely separate action for
that. editItem action does not care where the data is, and is it new
or existing. It just takes ID and pulls the object for presentation.
You may consider this bad style, but I think it is convenient.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Leon Rosenberg <st...@anotheria.net>.
I've read the article now too, and must say i can't disagree more.
First:
>HTML FORM is submitted from the input page, usually using POST request
method. Struts populates form bean (marked with [F]) with
>request data. Then form bean validates input and if something wrong, it
generates error messages. If validate() returns errors, Struts
>does not bother to call action class. Instead, it forwards to location,
which is defined in "input" property of <action> element. If,
>on the other hand, input data is correct, Struts calls execute() method of
the action class. It usually performs model update, then
>fills out form bean with output values, and forwards to JSP page, which
displays output data.
Especially the last one:
>fills out form bean with output values, and forwards to JSP page, which
displays output data
Is complete nonsense in my eyes. I've never seen an application doing this.
Maybe I haven't seen enough struts applications,
but our current application for example, with 1500 classes, 500 jsps, and
over 100K lines of code doesn't show this behaviour at a single place.
ActionForms are "the better way" to parse request after form submission.
That's it. Nothing less, nothing more.
...
Further in text:
> Form bean is used both for input and for output. If input and output page
uses same fields, this is OK, but usually this is not the
> case. So, one form has to combine input and output fields.
See above. I don't think it's struts typical, if it is, again, never seen
this before.
> On error action class is not called. This may be useful in some cases, but
not always
This depends solely on the validation technique. Actually we are using
validate methods of the ActionForm solely to perform javascript validation
on the client side (to reduce traffic for client) and to backup it on the
server side in case one switched off javascript.
What I do validate in Forms are things like length of a specific text field
or presence of needed fields.
If logic is required, the validation is performed in the action, or even in
the service layer.
>On error control is forwarded to location, defined in "input" property.
This property itself is a source of misunderstanding for
>Struts newbies, and makes clean request->processing->response sequence a
little fuzzy.
Typicall for all GUI applications, isn't it? If you don't like it, you can
override this behavior. Noone says you MUST use actionforms, struts has
enough power without action forms.
>Because in case of error most applications forward to input page instead of
redirecting, page is sent back to broswser immediately in >response to POST
request. This produces POSTDATA effect on reload, which results in double
sumbit.
Aehm... The double submit problem is not a problem of POST or GET request.
Ist a problem of bad programmed browsers, proxies etc, and there are enough
techniques to avoid it.
Since your preposition about "Traditional Struts request/response cycle"
isn't TRUE in my eyes, you provide a solution to a problem, that doesn't
exists :-)
Now seriously. Using ActionForms for result presentation is just a matter of
bad style, it doesn't mean, that struts is badstyles,
after all, everything, that can be misused, will be :-)
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: (OT) Acegi & Struts
Posted by Matt Raible <li...@raibledesigns.com>.
On May 11, 2005, at 3:26 AM, Marco Mistroni wrote:
> Hello all,
> Sorry for partially off-topic question, but I am looking
> For some feedback..
> Is anyone using (or has used, or plan to use) acegi security
> system(http://acegisecurity.sourceforge.net/)
> with Struts?
I'm using Acegi as part of AppFuse - of which Struts is the default web
framework. Here is a howto for converting from CMA to Acegi Security.
http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuseAuthentication
I really like Acegi b/c it has many additional features that other
security systems don't have. For example, the ability to get the
user's information at any layer in your application (via a ThreadLocal)
and the ability to easily control method invocations based on roles.
It's ACL feature is pretty nice too.
Matt
>
> Any feedback? Any recommendations for other security 'systems' to use
> with struts and spring?
>
> Thanx in advance and regards
> marco
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
(OT) Acegi & Struts
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello all,
Sorry for partially off-topic question, but I am looking
For some feedback..
Is anyone using (or has used, or plan to use) acegi security
system(http://acegisecurity.sourceforge.net/)
with Struts?
Any feedback? Any recommendations for other security 'systems' to use
with struts and spring?
Thanx in advance and regards
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Michael Jouravlev <jm...@gmail.com>.
On 5/10/05, Benedict, Paul C <pa...@merck.com> 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.
Perhaps, the wiki page does not have enough arguments and explanation,
why I believe this is the good way do Struts UI actions. If you can
spare 20 minutes, maybe you would like to read this arcticle:
http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost
And them check these two applications, they do exactly the same thing,
but this one http://www.superinterface.com/fwapp/viewList.do uses
in-server forward, and this one
http://www.superinterface.com/rdapp/viewList.do uses redirect via
browser (sorry, when I was updating the redirecting app, I lost
original pages with explanatory text, but the functionality is the
same).
Try them, try to refresh pages, to go back and forward, to delete item
from the list and refresh the list, etc. You will see how robust the
redirecting app is comparing to forwarding one.
> This technique is known as ActionChaining and, as I agree, it seems to be
> frowned upon:
> http://wiki.apache.org/struts/ActionChaining
Do you think that this technique is bad only because of someone else's
opinion? ;) Even King Arthur, Einstein and Von Braun made mistakes.
Plese, think it over again, and see i/o separation has its benefits.
Also, Ted Husted does not consider a single forward from one action to
another to be chaining ;)
> 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.
I see, this is what I call a DialogAction. I have this too, this is
slightly different type of separation, but it is there, too. First, i
submit input data to the action using POST, then I redirect to the
same action, and load the page using GET. Action decides, is it input
or output by request type. Form has session scope. Simple and it
works. To clean form I use a special "init" request parameter.
> 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 guess, you use approach like this:
http://wiki.apache.org/struts-data/attachments/StrutsCatalogInputOutputSeparation/attachments/actioncombo03.gif
I am totally not against it, I use it myself too. But here you
disagree with yourself. You just said, that you "do not like putting
any output data in the form unless it started as input". So, you _can_
use the same form for input and output? This is just a matter of
particular situation.
But I agree with you, that ActionForm is probably not the best place
to put output data. On the other hand, if I have a business object or
DTO, and a reference to this DTO in the form, this would work too,
would not it?
> I am ready to be disagreed with... But I want to know why.
Umm... I think I need to split the wiki page into two, or something.
There are two aspects:
* First, is how to separate data itself.
* Second, how to separate the _processes_ of input and output.
The second is important in order to provide better user experience and
to allow a user to click Refresh, Back and Forward wherever he likes,
and not to produce POSTDATA situations and double submits. As a user I
hate POSTDATA dialogs, they make me want to reach out for a shotgun
(but I do not have a shotgun). As a developer I hate to process double
submits and to handle tokens. POST->redirect->GET solves both my
problems as a user and as a developer problems.
Roundtrip? I do not care about roundtrip.
There are additional benefits of redirection like having a single URL
for GET. You can POST whatever data you like, but if you redirect
after your POST, and pull the page using GET, browser would use only
the GET location to include in session history. And if your GET
location is always the same, the session history will not grow.
Check out this link: http://www.superinterface.com/rdapp/viewList.do
Click "edit", try to enter some non-integer stuff. Do it several
times. Try to reload, see, no POSTDATA. Then click Back, see that you
return to the list _immediately_. You do not need to click Back as
many times, as many times you entered wrong data. This is what empty
GET after redirect gives you.
I definetely need to put more arguments, and to split article in two,
I guess. The subject is not clean enough, as I see.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Aladin Alaily <st...@aladin.ca>.
Dave Newton wrote:
> Isn't that where ActionForms are? In any case, nobody said it couldn't
> be encapsulated in some nice, tidy object.
You're absolutely right. This is exactly what I do. It's just that
when Paul said the following:
> I put my output data
> exclusively in request or session attributes as necessary, but never the
> form
I took it to mean that he literally puts attribute1->value1 ...
attributeN->valueN in the session or the request rather than in an
object (like an ActionForm).
Aladin
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Dave Newton <ne...@pingsite.com>.
Aladin Alaily wrote:
> 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.
Isn't that where ActionForms are? In any case, nobody said it couldn't
be encapsulated in some nice, tidy object.
One project I saw had "output" data in ActionForms: hit a page, the
ActionForm is loaded (for instance, with a list of headlines, etc.) by
Struts then used on the page as an output object.
I was opposed, although it was nice that it was magickally instantiated
and the logic was completely removed from the Action. However,
everything was tied to Struts and I couldn't reuse functionality in
non-Struts code.
I think whether or not ActionForms are input or output could be argued
either way. Even the Struts page says:
*"Note:* While ActionForm beans often have properties that correspond to
properties in your Model beans, the form beans themselves should be
considered a Controller component. As such, they are able to transfer
data between the Model and View layers."
That said, I've never (and most likely never will) put data into an
ActionForm that isn't destined for an HTML form: I like the _concept_ of
putting "output" in ActionForms but think that ActionForms are best
reserved for HTML forms. Output data belongs elsewhere, preferably in a
nice automagically-instantiated ActionForm analogue, decoupled from Struts.
Dave
Re: StrutsCatalogInputOutputSeparation
Posted by Pedro Salgado <sa...@04web.com>.
On 10/05/2005 22:21, "Aladin Alaily" <st...@aladin.ca> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Aladin Alaily <st...@aladin.ca>.
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.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: StrutsCatalogInputOutputSeparation
Posted by Pedro Salgado <sa...@04web.com>.
On 10/05/2005 21:30, "Benedict, Paul C" <pa...@merck.com> 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 also agree with you.
I even created some small package to make my own "viewbeans".
Pedro Salgado
>
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org