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
