Hi, Taking this to the list.
On 26.01.2010 23:44, Jason Rose (JIRA) wrote: > 1) Is it intended to just output the jcr:uuids of the nodes in the > collection? I was hoping that the servlet would retrieve the nodes that they > reference and serialize them. Yes, this is expected. The default JSON servlet just sends back the raw content. > > 2) If they are behaving as intended, is it trivial to write an esp or > override the servlets myself to implement that sort of behavior? This sort > of behavior was one of the biggest benefits I was hoping that sling had. Yes, it is. You can register a servlet or script to handle the JSON extension thus overwriting the default JSON renderer, though I would handle this with care (obviously). Best would be to restrict this overwriting to the resource type (or a resource super type) in question. For example considering the region nodes have the resource type "regions", you might register a script: /apps/regions/json.esp which would take precedence over the default GET servlet for the regions resources. Alternatively, if you want to differentiate between resolved joins (like following referneces) and plain output, you might want to use a selector, say "resolve", and register a script for that selector, as in: /apps/sling/servlet/default/resolve/json.esp This would be called for all requests of the form /a/b/c.resolve.json while the default behaviour is still available to your application. > > 3) Is this sort of approach the best way to implement a many-to-many > relationship where I need to traverse relationships in this manner? You mean REFERENCE properties ? My personal opinion is, that REFERENCE properties have a nice property supporting forth (referent to referee) and back (referee to referent) walking. But this comes at a high price in JCR 1.0, since REFERENCE properties ensure referential integrity. With JCR 2.0 WEAK_REFERENCE properties, this is loosened a bit. Still there is a price to pay for the back/forth referencing. So, what we do in our own application is to use path references, which proved stable enough, for forward references. For backward references, should we ever need it, we use JCR search. The price we pay for this is, that in the case of moving or removing the reference target, we have to manually update the reference. Hope this helps. Regards Felix > >> Multiple-value Reference Properties >> ----------------------------------- >> >> Key: SLING-1329 >> URL: https://issues.apache.org/jira/browse/SLING-1329 >> Project: Sling >> Issue Type: Bug >> Environment: Karaf 1.2.0, trunk build of sling installed using >> features.xml (rev 902845), java 1.6, maven 2.2.1 >> Reporter: Jason Rose >> Attachments: jiracase.zip >> >> >> I am creating 2 node subtrees for two entities with a many-to-many >> relationship to each other. I am implementing this relationship as a strong >> reference, multiple value property on each entity node under the subtrees. >> I'm loading in the data as nt:unstructured with mix:referenceable as the >> only addition, so I can make references between the two. The tree looks >> like this: >> /multiple-reference-property (root for this test) >> |--users >> |--user a(random uuid as its name) >> |--regions-single (single property reference to region a, seems to >> work) >> |--regions (multiple-valued reference property to regions a-e, >> renders fine as text but doesn't act as relationship if I try to traverse it >> via URL) >> |--users b-e, set up identically to user a >> |--regions >> |--region a(random uuid as its name) >> |--users-single (single property reference to user a, seems to work) >> |--users (multiple-valued reference property to users a-e, renders >> fine as text but doesn't act as a relationship if I try to traverse it via >> URL) >> I can successfully use URLs like >> localhost:8181/multiple-reference-property/regions/<uuid to region >> a>/users-single.<json, xml, txt doesn't matter they all work> >> What does not work is a URL like >> localhost:8181/multiple-reference-property/regions/<uuid to region >> a>/users.<xml, json, doesn't matter none work> >> The data is loaded via a bundle, since using the contentloader with flat >> files will be unfeasible later in my project's future, because it will need >> a very large and randomized dataset, which only seems easily doable by >> directly interacting with the JCR api. >> Of course if there is a more preferred way to implement a relationship like >> this, please let me know. I would strongly prefer to not use weak >> references in this case. >
