Consider these requests:
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable"
-Ftitle="Region 1" http://localhost:8888/test/regions/region1
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable"
-Ftitle="Region 2" http://localhost:8888/test/regions/region2
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable"
-Ftitle="Region 3" http://localhost:8888/test/regions/region3
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable"
-Ftitle="Region 4" http://localhost:8888/test/regions/region4
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable" -Ftitle="User
1" http://localhost:8888/test/users/user1
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable" -Ftitle="User
2" http://localhost:8888/test/users/user2
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable" -Ftitle="User
3" http://localhost:8888/test/users/user3
$ curl -u admin:admin -F"jcr:mixinTypes=mix:referenceable" -Ftitle="User
4" http://localhost:8888/test/users/user4
$ curl -u admin:admin -F"users=/test/users/user1"
-F"users=/test/users/user3" -F"us...@typehint=reference[]"
http://localhost:8888/test/regions/region1
$ curl -u admin:admin -F"regions=/test/regions/region1"
-F"regi...@typehint=reference[]" http://localhost:8888/test/users/user1
$ curl -u admin:admin -F"regions=/test/regions/region1"
-F"regi...@typehint=reference[]" http://localhost:8888/test/users/user3
This creates four regions and users and the many-to-many relationship
between region1 and users 1 and 3.
At this point,
$ curl http://localhost:8888/test/regions/region1.json
is going to return
{
"title":"Region 1",
"jcr:uuid":"759d2b99-837b-4758-9e48-f4dff7958c1f",
"jcr:mixinTypes":["mix:referenceable"],
"jcr:primaryType":"nt:unstructured",
"users":[
"a6d6c596-aef5-470f-8212-fc8129aa5296",
"b3342d99-75ff-4b70-bd3c-d3083d4b0298"
]
}
I'd like to see this:
{
"title":"Region 1",
"jcr:uuid":"759d2b99-837b-4758-9e48-f4dff7958c1f",
"jcr:mixinTypes":["mix:referenceable"],
"jcr:primaryType":"nt:unstructured",
"users":[
"/test/users/user1",
"/test/users/user2"
]
}
gist here: http://gist.github.com/289190
It sounds like you're saying even with this, you'd still want the users
array to be deferenced.
Justin
On 1/28/10 1:16 PM, Jason Rose wrote:
I just made this up. I'm not using CND files yet but rather creating
everything via the JCR api in an activator.
<example = 'http://example.com/example>
[example:region] > mix:referenceable
- example:external_uuid
- example:users (reference) multiple
[example:user] > mix:referenceable
- example:external_uuid
- example:regions (reference) multiple
I'd like to be able to dereference properties in a url to avoid the
situation I mentioned earlier, involving returning a large number of
paths to nodes and having to load them all one by one. I'd like to be
able to load all the contents of the nodes referenced by my users or
regions property and return them to the client.
-Jason
On Jan 28, 2010, at 11:05 AM, Justin Edelson wrote:
I'm not following you. Can you post your CND?
Justin
On 1/28/10 1:04 PM, Jason Rose wrote:
Then I'm on board with this. It actually makes it easier in my case
for the client to receive and post paths to nodes instead of
jcr:uuids, which I would like to avoid returning in the responses
from sling. Just to make sure we're on the same page, I'm thinking
of responses like this:
/regions/<uuid>.json
{
region: {
"external_uuid":"<someuuid>",
"users":[ "/users/<someUuid>", "/users/<someotherUuid>"]
}
}
What I'm not sure about is how to achieve the behavior I want, which
is something like this:
/regions/<uuid>/users.json
{
users:[
{"external_uuid":"<someuuid>", "regions":[...]},
{...}
]
}
Maybe there should be a selector, like users.traverse.json, or
something of the sort. I'm still not too knowledgeable about the
options we have.
-Jason
On Jan 28, 2010, at 10:32 AM, Justin Edelson wrote:
On 1/28/10 12:14 PM, Jason Rose wrote:
I think that it's fine to have them serialized to the client like
that if the request in question isn't calling for the target
nodes' data. I would prefer for them to store the jcr:uuids
internally since I am using hard references though, so I think
that storing the paths internally might lead to a bad state in
case nodes are moved or deleted.
To be clear, what I am describing below still has the references
stored as Reference properties (i.e. using the UUID), it just gets
transformed into a path upon output and (more importantly for the
issues I was running into yesterday) from a path on input.
My use cases usually will call for the data from a multiple valued
reference with say 50 nodes, and so returning all 50 entities as
json is considerably more efficient than returning 50 node paths
and requiring the js client to fire 50 more requests to populate
its datastore.
Good point. Still thinking about how to best make this pluggable...
Justin
-Jason
On Jan 27, 2010, at 5:14 PM, Justin Edelson wrote:
Jason-
I was looking at something similar today, but my approach is
slightly
different. What I would prefer to do is replace all UUIDs with
paths, both
for input and output.
So if /content/regions/region1 has a multi-valued Reference
property called
users, you'd get something like this:
{
'users' : [ '/content/users/user1', '/content/users/user2' ]
}
WDYT?
Justin
On Wed, Jan 27, 2010 at 5:19 PM, Jason Rose <[email protected]>
wrote:
Hello all,
Following up on the JIRA case that Felix quickly addressed and the
discussion that came out of it, it appears that sling will be
very useful in
my current project. I'm planning on using sling as my backend
with
sproutcore as the rich client front end. It seems the cleanest
way from a
REST perspective is to allow dereferencing properties in URLs so
that the
client can follow relationships.
In my previous posts, I was using an example of a many-to-many
relationship
between users and regions. I'll try to stick to that convention
in these
posts as well.
For example, if I wanted to see all the regions that all the
users assigned
to a specific region are assigned to, I think that path would
look like
this, omitting the URL prefix: "/regions/<uuid>/users/regions.json"
I'm interested in what the devs think about this sort of usage
of sling,
what sort of suggestions they have, and where in the code I
should look to
implement these changes.
-Jason
