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
