RestPathActionModel model matcher

[Alejandro Revilla]

This is a low priority observation (and may be just a config issue on
our end).

When using the handy 'restpathactions' module, we've noticed we cannot
specify a different action for a route with the same path but just a
different method (i.e. POST versus PUT) (may be we are doing something
wrong at config time in our routes.xml, sorry if that's the case).

Not a big deal, we can handle that on a single action and dispatch to
the appropriate one, but I was wondering if there is an easy fix to
that.

Not sure about the best solution, but was thinking that perhaps we
could either use the method as part of the path for the uri matcher
(dirty hack) or in RestPathAction around line 71 when we call the
matcher, we could also check that rm.getMethod() actually matches.

@apr

[Florin T.PATRASCU]

Hehe, you found it :) I initially started to implement the support for matching the method of the request as well but I wasn't satisfied completely with the design and left that to bake until someone will find a need for it. While pure Java action can benefit from reflection and would easily allow me to just execute a GET()/PUT()/etc... method this way writing one action and having different execution points automatically invoked based on the request method, a scripting based action will pose some difficulties, and there is where I left it.

With the current code, in the org.jpublish.module.restpathactions.RestPathActionModel, as you can see, there is a "methods" property, and the plan was to allow the user to configure a route like this:

<routes>
...
<route path="demo/foo" method="GET|POST" action="rest/SomeAction.bsh">
...

If you define a route like the example above, the "method" config attribute will be loaded by the RestPathActionsModule and made available to the matcher, eventually will be interpreted around the line 71 in the RestPathAction, as you very well noticed, see next fragment.

If this workaround is acceptable, then I'll finalize the implementation by simply replacing lines 70-72 with something like this:

// todo: add uppercase or lowercase safe comparison ...
boolean methodMatchesToo = rm.getMethods() != null && rm.getMethods().contains(method);
if (matcher.matches(path) && methodMatchesToo) { ... // GET by default if methods === null

That will do it. What do you think?

V/r
-florin

> --
> You received this message because you are subscribed to the Google Groups "JPublish User Group" group.
> To post to this group, send email to jpubli...@googlegroups.com.
> To unsubscribe from this group, send email to jpublish-use...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jpublish-user?hl=en.
>

[Florin]

yep, I believe this will work.

Alejandro, please check http://code.google.com/p/jpublish/source/detail?r=279
and let me know if the new behaviour is working as intended.

Basically you can do this now:

<route path="demo/foo" method="GET|POST" action="rest/

SomeGetPostAction.bsh">
<route path="demo/foo" method="DELETE" action="rest/
DeleteAction.bsh">


V/r
-florin



On Aug 7, 5:00 pm, "Florin T.PATRASCU" <florin.patra...@gmail.com>
wrote:

[Alejandro Revilla]

And what about the "This is a low priority observation", today is
Sunday! :)

Your patch looks perfect, than you!

On Aug 7, 6:40 pm, Florin <florin.patra...@gmail.com> wrote:
> yep, I believe this will work.
>

> Alejandro, please checkhttp://code.google.com/p/jpublish/source/detail?r=279

[Florin T.PATRASCU]

was just a minor thing, hope it helps. We drink Java Sundays too, right?! :)

V/r
-florin