Michael, I read your article again two more times, and I have to say I really do like it. It's an ingenious solution; so I am warming up to it in some areas. Regardless, this email thread will certainly help everyone think through the problem :)
Here are some further reflections: 1) I wrote: "do not like putting any output data in the form unless it started as input." This needs to be framed within the context of normal Struts development. If I am going to return data that will be returned in an HTML form, the appropriate form properties are populated. My sentence is directed towards non-HTML display, what I term "output data", because it has no further purpose besides display purposes (i.e.: output). 2) You wrote: "Ted Husted does not consider a single forward from one action to another to be chaining ;)" Agreed. He explicitly states this when referencing Tiles or a JSP page -- a view needs to be returned. However, my point is virtually moot because the conclusion of your article is not to forward but to redirect. 3) The redirection for errors requires Struts 1.2.7 or later .. or you will lose the error messages. :-) Because redirection creates multiple requests, it does imply that all forms need to become session based. How necessary is this for an entire web application? My general rule is to keep forms in request-scope, because it allows multiple views of a form to be accessed during a session, plus clean-up is automatic. I know your methodology is to associate a random identifier to a session form, but are you concerned that the session can be filled with tons of objects? A malicious user, assuming he knew your methodology, could just F5 the web page and force unlimited memory allocation via the session. Thanks, Paul -----Original Message----- From: Michael Jouravlev [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 10, 2005 4:51 PM To: Struts Users Mailing List Subject: Re: StrutsCatalogInputOutputSeparation On 5/10/05, Benedict, Paul C <[EMAIL PROTECTED]> 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/StrutsCatalogInputOutputSepar ation/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ------------------------------------------------------------------------------ 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]
