Jeromy Evans wrote:
Wouldn't it be the case for most people that specify params in the action definition that they wouldn't want those overridden by
request params?
I don't know the history but I think you make a good point.

It a couple more people agree I'll create a JIRA issue and post a patch.

I think you've done a good thing in your example. At least your decision to create three different actions with a unique url for each type of resource should make REST purists happier than the original generic form.

The problem is that I have 5 nouns in this system, and between them 59 or 77 relationships (depending on how you count). So building a separate action definition for them is still too many, and when more than one constraint is specified the additional ones will still be ugly.

I had gone with the breakdown I did earlier because I figured the smallest number that wasn't growing was 5, and that capped me to 10 arguments: For each dimension an argument that said "There's a THIS constraint with an object of this type" and another that said "This is the object with which you have that constraint" (I had always realized the unfortunate side-effect being that you could only have one constraint per noun applied.)

But in thinking all this through I finally realize that as long as I make sure all the relationship names indicate a distinct noun type, I don't have triples: I really just have a list of tuples: (constraint-name, object-name)

Lets see if I can come up with an off-the-cuff example:
http://localhost:8080/appname/widgets/madeByCompany/acme/neededFor/roadRunnerTrapXQ4/distributedThroughCompany/acmeMailOrder.html
Would result in a page listing widgets that fit all three constraints.
Of course there's still the need for other arguments that don't fit this constraint model, so I don't know if
http://localhost:8080/appname/widgets/madeByCompany/acme/neededFor/roadRunnerTrapXQ4/distributedThroughCompany/acmeMailOrder.html?startAt=50
or
http://localhost:8080/appname/widgets/madeByCompany/acme/neededFor/roadRunnerTrapXQ4/distributedThroughCompany/acmeMailOrder/startAt/50.html
is better (for displaying the next page, for example).

What I would love is a way to take all /widgets/* urls, and be able to quickly wind up with a list of tuples.

RestfulActionMapper doesn't help:
http://HOST/ACTION_NAME/PARAM_NAME1/PARAM_VALUE1/PARAM_NAME2/PARAM_VALUE2

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?)

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?

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...

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to