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 21:57:38 GMT
One more thing:

On 5/10/05, Leon Rosenberg <> 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:
For additional commands, e-mail:

View raw message