struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Addition of two new actions
Date Fri, 01 Aug 2003 17:41:54 GMT


On Fri, 1 Aug 2003, Steve Raeburn wrote:

> Date: Fri, 1 Aug 2003 10:01:35 -0700
> From: Steve Raeburn <sraeburn@apache.org>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>,
>      sraeburn@apache.org
> To: Struts Developers List <struts-dev@jakarta.apache.org>
> Subject: RE: Addition of two new actions
>
> ParameterDispatchAction resolves the method directly from the value of the
> parameter. parameter="add" would look for a method in the user's subclass
> named 'add'.
>
> Unlike DispatchAction, the various action definitions do not need to share
> the same attributes. Each action is defined separately with its own path,
> form, validation etc.
>
> For example, you could combine all the CRUD related actions for a business
> object into a single action class to better organize and encapsulate code,
> but still be able to validate forms in some actions but not in others.
>
> I don't see any technical reason why this couldn't be combined with
> DispatchAction but it feels like cramming too much in to a single class to
> me. (There's already a request in Bugzilla to combine LookupDispatchAction
> with DispatchAction). I prefer that each class do one thing and do it well
> rather than try to shoehorn several different resolution methods into a
> single class.
>

So, what you really want is LookupDispatchAction without requiring the
developer to create the map-related methods?  I think you already get the
abililty to combine CRUD related actions and things like that.  If so,
then implementing a default getKeyMethodMap() in LookupDispatchAction
might accomplish the same goal, without requiring another action.  Such a
default implementation could examine the current LookupDispatchAction
subclass and create the mapping information automatically.

Don't get me wrong ... I like the idea behind what you're proposing.  I
just think we might already have it (with the potential to improve ease of
use by not forcing people to implement getKeyMethodMap() for a common use
case).

> Steve

Craig


>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: August 1, 2003 9:01 AM
> > To: Struts Developers List; sraeburn@apache.org
> > Subject: Re: Addition of two new actions
> >
> >
> >
> >
> > On Thu, 31 Jul 2003, Steve Raeburn wrote:
> >
> > > Date: Thu, 31 Jul 2003 23:10:59 -0700
> > > From: Steve Raeburn <sraeburn@apache.org>
> > > Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>,
> > >      sraeburn@apache.org
> > > To: Struts Developers List <struts-dev@jakarta.apache.org>
> > > Subject: Addition of two new actions
> > >
> > > I'd like to add two new actions to org.apache.struts.actions that I find
> > > particularly useful.
> > >
> > > 1. SuccessAction - A simple action that forwards control to an
> > ActionFoward
> > > named "success".
> > >
> > > This is a very simple action, but I find it exceptionally useful,
> > > particularly in the early stages of development when it can act as a
> > > placeholder for as-yet undeveloped actions.
> > >
> > >   public ActionForward execute(
> > >     ActionMapping mapping,
> > >     ActionForm form,
> > >     HttpServletRequest request,
> > >     HttpServletResponse response)
> > >     throws Exception {
> > >
> > >     ActionForward forward = mapping.findForward("success");
> > >       if (forward == null) {
> > >         String message =
> > >           messages.getMessage("success.required", mapping.getPath());
> > >         log.error(message);
> > >         throw new ServletException(message);
> > >       }
> > >       return forward;
> > >     }
> > >
> >
> > I agree with others in the thread pointing out that this would be
> > redundant.
> >
> > > 2. ParameterDispatchAction - A DispatchAction that selects a
> > handler method
> > > using the value of the ActionMapping parameter.
> > >
> > > This is as per the suggestion by Anthony Kay via Bugzilla
> > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117>,
> > except I prefer
> > > the name ParameterDispatchAction to his suggestion of
> > ConfigDispatchAction
> > > as I think it's more descriptive of what the class actually
> > does. Other than
> > > the name change, I've just tidied up the Javadoc and changed the
> > > 'unspecified' method to throw an Exception (as in DispatchAction) rather
> > > than return an Http error code.
> > >
> > > If no one has any problems with adding these two, I'll put them
> > in tomorrow.
> >
> > Could you help me understand how this is different from what
> > DispatchAction already does, or why we couldn't just update DispatchAction
> > itself to add any additional functionality it represents?
> >
> > >
> > >
> > > Steve
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message