struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Jouravlev <>
Subject Re: StrutsCatalogInputOutputSeparation
Date Tue, 10 May 2005 20:50:40 GMT
On 5/10/05, 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.

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:
And them check these two applications, they do exactly the same thing,
but this one uses
in-server forward, and this one uses redirect via
browser (sorry, when I was updating the redirecting app, I lost
original pages with explanatory text, but the functionality is the

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:

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:

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:
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.


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

View raw message