Dale Newfield wrote:
Lets see if I can come up with an off-the-cuff example:
Ok, I see what you're doing now.
Because I still can't find people that are friends with both joe and amy:
http://localhost:8080/social-networking-app-de-jur/users/friendsOf/joe/friendsOf/amy.html
because one constraint will overwrite the next of the same type.
And I don't think this is really what the rest plugin does, either.
(Am I wrong?)
Yeah, I'm certain no mapping supports params like the "friendOf' and
"friendOf" example at the moment. The NamedVariablePatternMatcher is
based on fixed patterns:
eg.
@Namespace("users/{relationshipA}/{usernameA}/{relationshipB}/{usernameB}")
In order to prevent a multitude of urls, I guess I could be careful
and alphabetize the constraints when constructing urls (alphabetizing
values when constraints are multiply present. So I would need to
detect that this is incorrect:
http://localhost:8080/social-networking-app-de-jur/users/friendsOf/joe/friendsOf/amy.html
and redirect to:
http://localhost:8080/social-networking-app-de-jur/users/friendsOf/amy/friendsOf/joe.html
before returning a result.
So now that I better understand how to most cleanly describe the urls
to request information from my system, how do I go about implementing
that mapping? From what I understand of the various rest tools we've
got, this isn't the way any of them work. Should I just send all
"/widgets/*" to a single action that does it's own URL parsing?
I think this is an argument for a custom action mapper that supports
your expressions. It's up to the mapper to parse the URL to extract the
namespace, action and params. The mappers seem fairly straight-forward.
Actually, I don't think any of the existing mappers can send
"/widgets/*" to your action because I think they would confuse the paths
training widgets with the namespace or action name (except perhaps when
it fails it will fallback to an in the default namespace)..
I'd start by looking at the parseNameAndNamespace method of
http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/RestActionMapper.java
and
http://svn.apache.org/repos/asf/struts/struts2/trunk/core/src/main/java/org/apache/struts2/dispatcher/mapper/DefaultActionMapper.java
And create you're own.
Since you asked, the REST plugin with the NamedVariablePatternMatcher
enabled would allow you to move some params into the path to tidy it
up a bit (and address each resource with a unique url):
This might be what I'm looking for... I can "read the source, luke"
at
http://svn.opensymphony.com/fisheye/browse/~raw,r=1664/xwork/trunk/src/java/com/opensymphony/xwork2/util/NamedVariablePatternMatcher.java
But I don't see *any* documentation for this. Where exactly would I
specify those patterns described in the javadoc at the top of that
java? I don't understand how NamedVariablePatternMatcher relates to
the REST plugin...
The NamedVariablePatternMatcher isn't documented at all yet as far as I
know (except perhaps in Don's presentation - haven't checked) [1]
The relationship to the REST plugin is that it was written to support
namespace parameters for it [2]. It could probably be used with the
normal action mapper or smarturls but I doubt anyone's tried that yet.
It's enabled by overridding the PatternMatcher bean in struts.xml:
<bean type="com.opensymphony.xwork2.util.PatternMatcher" name="struts"
class="com.opensymphony.xwork2.util.NamedVariablePatternMatcher"/>
(see struts-default.xml for comparison)
The patterns mentioned in the javadoc are assumed to be specified using
@Namespace within your action (rest/codebehind) but I suppose you could
specify them with namespace attributes in struts.xml too (I'm guessing)
as it all results in the same config.
Hope some of this helps. I haven't tried anything as complicated or
flexible as you're doing with action params.
[1] http://www.jroller.com/mrdon/entry/struts_2_and_rest_apachecon
[2]
http://www.nabble.com/-S2.1--url-action-mapping-problem-(restful)-t4695060.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
