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/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
