I think this does the right thing if you return Action.SUCCESS in your
remove() action method instead of "remove". Otherwise you'll need a
custom result mapping for that new result string.
On Tue, Dec 14, 2010 at 8:57 AM, <stanl...@gmail.com> wrote:
> I began writing about the 2.2.1 convention plugin and naturally started
> writing code. I especially like not having to code XML when my file naming
> is clean and straightforward. I started off with a package named
> *com.foo.actions.music* which resolves to the namespace (URL)* /music*.
> Next I created an Action there call* Instruments* which is accessible
> via*/music/instruments
> * where the *execute *method is invoked and the resulting
> *WEB-INF/content/music/instruments.jsp
> *displayed. So now I want to experiment with specialized variations on the
> URL in order to execute methods other than execute. I added a method
>
> �...@action("/remove")
> public String remove() {
> return "remove";
> }
>
> to my *Instruments *action and tried the following URL in the browser*
> /music/instruments/remove.
> *The remove method was invoked where it returned the string "remove." I
> expected this to resolve to
> *WEB-INF/content/music/instruments-remove.jsp, *which
> it **did not**. Instead I received that oh-so-familiar
>
> *Messages*:
> No result defined for action com.foo.actions.music.InstrumentsAction and
> result remove
>
> After several experiments and readings, I added the following annotation:
>
> @Action(value = "/remove", results = { @Result(name = "remove", type =
> "dispatcher", location = "music/instruments-remove.jsp") })
> public String remove() {
> return "remove";
> }
>
> which has both * /music/instruments *and* **
> /music/instruments/remove *working
> fine. However, as I study this annotation, it looks like the convention has
> fallen down and I am simply coding annotations where I would have wired up
> XML glue. I realize there is support for REST and wildcards, but I would
> like to see if anyone can throw me a bone vis-a-vis the annotations plug-in
> and support for methods beyond execute(). I realize I could have if/else
> code in execute() that returns this string or that, but seriously?
>
--
Allen Lee
Center for the Study of Institutional Diversity [http://csid.asu.edu]
Arizona State University | P.O. Box 872402 | Tempe, Arizona 85287-2402
Office: 480.727.0401 | Fax: 480.965.7671
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
