RE: How to name, package Actions

[Robert Scaduto <rs...@douwantit.com>]

In response to your first question, in my experience I try to name action
classes after what they actually do vs. what calls them.  I have done this
because in several instances I have been able to re-use actions in different
parts of the web site using different action mappings.  By naming it
specifically for scenario A it might be confusing or misleading in scenario
B.

To exemplify the two actions you presented, I would name them...

action1:  ConfirmDeleteWidgetAction
action2:  DeleteWidgetAction

This way if you wanted to delete the widget somewhere else in your web app
without the confirm check, the mapping would make sense at first glance. I
you wanted to get real smart you could even develop a ConfirmAction base
class to handle the semantics of confirming another action :)

In response to question 2.  It all depends. There is always a delicate
balance between too much packaging and not enough. It depends on your app.
For example if you have an app with 4-5 actions you might just want to put
the actions and the forms in one package.  If you had an app with 10-15
actions you might want to split up the actions and the forms in to separate
packages.  For apps with still more actions you might do it based on use
cases like you mentioned in your OPTION 2. I'm a firm believer in planning
on unplanned growth so I think OPTION 2 is probably the most flexible and
self-documenting.

Just my 2 cents.

-Robert Scaduto

-----Original Message-----
From: Molitor, Stephen [mailto:SMolitor@erac.com]
Sent: Thursday, February 21, 2002 4:19 PM
To: 'Struts Users Mailing List'
Subject: How to name, package Actions


I have two best-practices questions:

FIRST QUESTION:  How best to name Action classes?  Do you name an action
after the button that initiates it, the place it comes from?  Or, do you
name the action for what it goes to?  Or, for what the action does -- but
sometimes it's not so simple.  For example, imagine this scenario:

1.  From the 'Show Widget' page, user selects the 'Delete Widget' button.
2.  action1 is performed, which forwards to the 'Are You Sure?' page.
4.  User selects 'yes'
5.  action2 is performed, which physically deletes the record.

What are good names for action1 and action2?  If you name your actions for
the user gestures that trigger them, you might have this:

action1:  DeleteWidgetAction
action2:  YesReallyDeleteTheWidgetAction

Naming the first action 'DeleteWidgetAction' seems to make sense, since its
triggered by clicking on the 'Delete Widget' button.  But, then it's hard to
come up with a name for action2.  Plus, action1's name is misleading,
because it doesn't actually perform the delete.  OK, lets try naming the
actions after what they really do:

action1:  ConfirmDeleteWidgetAction
action2:  DeleteWidgetAction

This seems a bit better, but action1's name is a bit awkward.

In one way, Actions are like events triggered by clicking on something.  In
another sense, Actions represent the transition between two states, the
previous and next pages.  Or, they're just reusable commands.  This last
view is probably the most accurate, but I find it hard to come up with names
for commands.  Any heuristices or guidelines for naming actions would be
appreciated.


SECOND QUESTION:
How best to package Actions and ActionForms?  It's no problem for small
apps, but becomes a problem for larger ones.  Do you have lots of small
packages?  Do you put ActionForms and Actions in the same package?   Or,
separate sub-packages for Actions and ActionForms?

Lets say I working for an application called 'MyApp', for a company called
'Acme', and that there's a set of pages in the app dealing with user
registration.  Here are some packaging options:

OPTION 1 - By app --> sub-app
com.acme.myapp.registration.Form1
com.acme.myapp.registration.Form2
com.acme.myapp.registration.Action1
com.acme.myapp.registration.Action2

OPTION 2 - By app --> sub-app --> object type
com.acme.myapp.registration.forms.Form1
com.acme.myapp.registration.forms.Form2
com.acme.myapp.registration.actions.Action1
com.acme.myapp.registration.actions.Action2

OPTION 3 - By app --> object type --> sub-app
com.acme.myapp.forms.registration.Form1
com.acme.myapp.forms.registration.Form2
com.acme.myapp.actions.registration.Action1
com.acme.myapp.actions.registration.Action2

(I don't care for option 3.)

Any thoughts, other schemes?  I presume one would a matching sub-directory
structure for the JSP's.


Thanks!

Steve Molitor
smolitor@erac.com














--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>