Re: I am getting frustrated with LookupDispatchAction

[Michael Jouravlev <jm...@gmail.com>]

On 10/19/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Michael Jouravlev on 19/10/05 00:44, wrote:
> > On 10/18/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> >>Secondly, getKeyMethodMap() looks really clunky - is there no way this
> >>can be pushed into the struts-config.xml?
> >
> >
> > It can be done, but if this to be defined inside existing structures
> > like <action>, then I would have to change Struts code. Another way is
> > to define it somewhere else like <component> instead of <action> or
> > just <action-events>, in this case you would need to include custom
> > ruleset object into web.xml. The latter would be easier because Struts
> > code would not be changed.
> >
> > I will think about moving map to config file, but frankly I do not
> > consider it a priority. Why you don't like it in the class file?
>
> Because it's just a strings that go in a map. It's more easily readable
> in a config file and it keeps them all in one place instead of having to
> open each action. Obviously that only counts when you are looking at a
> big project, but it does make an impact.

I did that, but it works only with new syntax, when you use
<component> instead of <action>. Having a separate XML element to
define an action mapping is easier, because it allows to mix both
<action> and <component> in one config file, and it does not require
changing the Struts code. All I needed is just to add a new rule set.
So, how about this:

<!-- Home page. Handles welcome menu, main menu and language selection -->
<component path = "/Home"
  view = "/mailreaderpages/home.jsp"
  type = "net.jspcontrols.mailreader.HomeAction">

  <!-- Input events (request keys for submit buttons) -->
  <event name = "DIALOG-EVENT-LOGON" handler = "onLogon"/>
  <event name = "DIALOG-EVENT-SIGNUP" handler = "onAccountSignup"/>
  <event name = "DIALOG-EVENT-ACCUPDATE" handler = "onAccountUpdate"/>
  <event name = "DIALOG-EVENT-SUBSCRIPTIONS" handler = "onSubscriptions"/>

  <!-- Transfer from one action to another, usually using redirection -->
  <transfer name = "subscriptions" path =
"/Subscriptions.do?DIALOG-EVENT-INIT"/>

  <!-- Render a view, usually by forwarding to a JSP page -->
  <render name = "failure" path = "/mailreaderpages/error.jsp" />
</component>

> However I just thought of a better idea. Impose a rule that the name of
> the Action method should be prefixed by the prefix and that should be
> used as the name of each submit button. If the map is initialised at
> construction by reflection, it would make it all more intuitive and
> easier to code, with the added advantage that you would have one less
> place where the programmer would make a mistake.

I'd rather not do that. First, I don't want to introduce any magic
into Java code. Also, there is a better way of achieving that without
magic (umm, with less magic if you want) using annotations, like Tim
Fennel did in Stripes:

@UrlBinding("/quickstart/Calculator.action")
public class CalculatorActionBean implements ActionBean {
    ...
    @HandlesEvent("Addition") @DefaultHandler
    public Resolution addNumbers() {
        ...
        return new ForwardResolution("/quickstart/index.jsp");
    }
}

So, I don't want to redo what is already done by some ;-) But, Tim
strives to minimize XML configuration, while your first desire was to
move mapping configuration from action to XML, so I guess you would
like what I have implemented ;-)

Another choice would be to encode handler methods' names directly into
request keys, and to process submits with something like this:

http://issues.apache.org/bugzilla/attachment.cgi?id=15762

See javadoc comments for usage. I think this is something that could
find its place among Struts core actions.

What do you think? One more thing: you have to either define mapping
in xml file, or in an action, but not in both places (internally, I
check map variable for null). Is this OK or you want to refine XML
mapping in Java code?

Michael.

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