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]
