You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Struts Newsgroup (@Basebeans.com)" <st...@basebeans.com> on 2002/07/05 17:25:02 UTC

Re: [Struts Tips] #2 - Use DispatchAction to organize related operations

Subject: Re: [Struts Tips] #2 - Use DispatchAction to organize related operations
From: "Sebastian Millies" <s....@ids-scheer.de>
 ===
It's a little late, but I only got to see this posting just now.
I've got a question about this approach: why not just define
different actions in struts-config.xml which map to the same
action class? This would 1) obviate the need to introduce
an additional "dispatch" field, and 2) enable role-based
action access.

Of course you might still want your action class to automatically
call a specific perform-method when it is invoked, using reflection. If you
want to do that, wouldn't it be easiest to implement an ActionMapping
class with an extra field in order to map the action name to the
method name?

I haven't seen tip #3, so I'm sorry if this comment isn't relevant in
the kight of waht may follow.

-- Sebastian

"Jon.Ridgway" <Jo...@upco.co.uk> schrieb im Newsbeitrag
news:mailman.1022846461.17718.struts@basebeans.com...
> Hi Ted,
>
> I have a question about the dispatch action. On this face of it this seems
> like an excellent idea, but does it integrate with the role based action
> concept.
>
> If for example an administrator can add and delete but an employee can
only
> update is there a way to specify declaratively which roles have access to
> which methods. Or should we create separate actions if this functionality
is
> required.
>
> Hope the question makes sense....
>
> Jon.
>
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: 31 May 2002 12:12
> To: struts-user@jakarta.apache.org
> Subject: [Struts Tips] #2 - Use DispatchAction to organize related
> operations
>
> Any software application is defined by the things it can do for you. In
> a Struts Web application, the things an application does is usually
> defined by its action-mapping elements. An action-mapping is designed to
> be the target of an HTML form, and is often used with hyperlinks as
> well.
>
> Each action-mapping can specify a Struts Action class as its handler. In
> larger applications, developers can find themselves managing dozens or
> even hundreds of Action classes.
>
> In practice, many of these Action classes handle related operations,
> often evidenced by their name. A package might include separate
> RegCreate, RegSave, and RegDelete Actions, which just perform different
> operations on the same RegBean object. Since all of these operations are
> usually handled by the same JSP page, it would be handy to also have
> them handled by the same Struts Action.
>
> A very simple way to do this is to have the submit button modify a field
> in the form which indicates which operation to perform.
>
> <SCRIPT>
> function set(target) {
>  document.forms[0].dispatch.value=target;
> }
> </SCRIPT>
>
> <html:hidden property="dispatch" value="error"/>
> <html:submit onclick="set('save');">SAVE</html:submit>
> <html:submit onclick="set('create');">SAVE AS NEW</html:submitl>
> <html:submit onclick="set('delete);">DELETE</html:submit>
>
> Then, in the Action you can setup different methods to handle the
> different operations, and branch to one or the other depending on which
> value is passed in the dispatch field.
>
> String dispatch = myForm.getDispatch();
>
> if ("create".equals(dispatch)) { ...
>
> if ("save".equals(dispatch)) { ...
>
> The Struts Dispatch Action is designed to do exactly the same thing, but
> without messy branching logic. The base perform method will check a
> dispatch field for you, and invoke the indicated method. The only catch
> is that the dispatch methods must use the same signature as perform.
> This is a very modest requirement, since in practice you usually end up
> doing that anyway.
>
> To convert an Action that was switching on a dispatch field to a
> DispatchAction, you simply need to create methods like this
>
>     public ActionForward create(ActionMapping mapping,
>                  ActionForm form,
>                  HttpServletRequest request,
>                  HttpServletResponse response)
>     throws IOException, ServletException { ...
>
>     public ActionForward save(ActionMapping mapping,
>                  ActionForm form,
>                  HttpServletRequest request,
>                  HttpServletResponse response)
>     throws IOException, ServletException { ...
>
> Cool. But do you have to use a property named dispatch? No, you don't.
> The other step is to specify the name of of the "dispatch" property as
> the "parameter" property of the action-mapping. So a mapping for our
> example might look like this:
>
>             <action
>                 path="/reg/dispatch"
>                 type="app.reg.RegDispatch"
>                 name="regForm"
>                 scope="request"
>                 validate="true"
>                 parameter="dispatch"/> // Which parameter to use
>
> If you wanted to use the property "o" instead, as in o=create, you would
> change the mapping to
>
>             <action
>                 path="/reg/dispatch"
>                 type="app.reg.RegDispatch"
>                 name="regForm"
>                 scope="request"
>                 validate="true"
>                 parameter="o"/> // Look for o=dispatchMethod
>
> Again, very cool. But why use a JavaScript button in the first place?
> Why not use several buttons named "dispatch" and use the values to
> specify the operation.
>
> You can, but the value of the button is also its label. This means if
> the page designers want to label the button something different, they
> have to coordinate with the Action programmer. Worse, localization
> becomes virtualy impossible.
>
> If you prefer not to use JavaScript buttons, you can use the
> DispatchLookup Action instead. This works much like the DispatchAction,
> but requires more setup. We'll explore the DispatchLookup Action in Tip
> #3.
>
> HTH, Ted.
>
> ---
>
> Struts Tips premiere twice weekly on the MVC-Programmers List. To
> subscribe, visit BaseBean Engineering < http://www.basebeans.com >.
>
> An archive of past tips, like this one, is available at <
> http://jguru.com/faq/subtopic.jsp?topicID=893704 >.
>
> About Ted. Ted Husted is an active Struts Committer. He also moderates
> the Struts mailing list and the JGuru Struts
> FAQ.
>
> Copyright Ted Husted 2002. All rights reserved.
>
> _______________________________________________
> MVC-Programmers mailing list
> MVC-Programmers@basebeans.com
> http://www.basebeans.com:8081/mailman/listinfo/mvc-programmers
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> The contents of this email are intended only for the named addressees and
> may contain confidential and/or privileged material. If received in error
> please contact UPCO on +44 (0) 113 201 0600 and then delete the entire
> e-mail from your system. Unauthorised review, distribution, disclosure or
> other use of this information could constitute a breach of confidence.
Your
> co-operation in this matter is greatly appreciated.
>
> --
> 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>