Action Organization (was: Action chaining)

[Matt Raible]

I can't help chiming in as I'm in the midst of writing an example application using Struts for a Wrox book (Professional JSP 2.0). On my last Struts application, I used LookupDispatchAction's for all my actions. I basically organized it by entities, so that I had a UserAction, SearchAction, EventAction for the different types of activities. This seemed to work pretty well, and each class had their respective CRUD details.

What Erik seems to be suggesting is having a handful of generic actions - so you end up with DeleteAction, SaveAction, etc. that maybe use reflection to figure out the entity to delete, save, etc? Am I reading this correctly? Sounds like a neat idea, and would probably work, unless you had to have custom business logic for the deletion of an entity. For instance, when I delete a user, I need to delete all other entities associated with that user. Hmmm, sounds like I might want to stick with my LDA architecture. Thoughts?

Matt


On Thursday, December 12, 2002, at 01:43 PM, Andre Beskrowni wrote:

just for the record, i'm in complete agreement with erik on this issue. i
can remember reading warnings about how chaining actions isn't clean design
a long time ago. and for a while i heeded those warnings. but i eventually
found myself using the exact same pattern that erik mentioned when he
started this discussion. it's modular and clean. if someone has a better
suggestion than:
(1) call your delete action
(2) forward to list action
i'd like to see it, because it hasn't come up so far in this discussion.

i have to say, all of this "be careful" stuff seems a little dramatic. it
seems the same admonishments could be used about writing methods whenever
you're using call-by-reference.

ab

-----Original Message-----
From: Erik Hatcher [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 12, 2002 2:02 PM
To: Struts Developers List
Subject: Re: Action chaining


Eddie Bush wrote:

Erik Hatcher wrote:

There is no question that there are issues with forwarding

with form

population and such, and the known issue with multipart

data (which is

an isolated use-case anyway).

The multipart issues exists regardless of whether you are

chaining or

not - no?  I was of the impression that was the case.  The

single thing

I see (and it's entirely possible I'm being short-sighted)

is that your

form would be repopulated (which could be very evil to

track down if you

hadn't already thought through the possibility of it happening).
Redirecting avoids this issue altogether by causing another

request to

be created.

We're talking a little non-sequitor here.  Action chaining in
no way is
tied to whether I'm doing redirects or server-side forwards -
either are
possible with them.

But you are absolutely correct about these issues.  I've not
encountered
them except with the multipart issue in a prior project.  I
don't modify
a form bean in these actions.  The only actions that modify a
form bean
in our system are the "setup" actions that populate a form prior to
forwarding to the JSP, and those would always be at the end
of a chain.

Just to clarify - I'm not chaining tons of stuff together, just for
situations like I've mentioned.  Generally speaking I'm doing "text
book" Struts development, but I find that action chaining is
very handy
in certain situations, and I'm thankful that Struts actually
allows it
rather than forbid it altogether somehow.

Its really just food for thought for the next architecture as
well as to
gather ideas from others on how they implement similar needs.

	Erik




--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>