hi guys,

On Jan 22, 2008 9:47 AM, Peter Svensson <[EMAIL PROTECTED]> wrote:
> DOJOTree vs. generic json tree

You are bringing up very good point.

First of all I think the default serialization should not include
"jcr:primaryType" (and other system props) and I still think that this
is something that we did not get around to fix for ujax.

I reported an Issue for that:
https://issues.apache.org/jira/browse/SLING-182

I personally believe that we should support a simple way for people to
get to different views of the same json (like the DOJO tree structure).
Now, I am not sure if we need to do that on the server side, maybe Peter
can shed some light on this: If you would acquire the data through
something like ujax.getContent() and then manipulate the object tree
on the client side, can you then supply the data for the DOJO tree
after that from a client side method or does the DOJO tree strictly require
a URL?

If it is easier to do things server sided then I would recommend to extend
the "filter" mechanisms on the server side. Now looking at:

/mynode.0.json
/mynode.1.json
/mynode.infinity.json

... from a url perspective something like ...

/mynode.all.0.json
/mynode.all.1.json

... or ...

/mynode.dojotree.infinity.json

could do the trick...

thoughts?

regards,
david

On 1/22/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> (renaming the thread to attract attention of our JSON folks)
>
> On Jan 22, 2008 9:47 AM, Peter Svensson <[EMAIL PROTECTED]> wrote:
> > ...The json that would be nice to have is something like this;
> >
> > {
> >     label: 'name',
> >     identifier: 'name',
> >     items:
> >     [
> >         { name:'Fruit', type:'category'},
> >         { name:'Cinammon', type: 'category',
> >         children:
> >         [
> >         { name:'Cinammon Roll', type:'poptart' },
> >         { name:'Brown Sugar Cinnamon', type:'poptart' },
> >         { name:'French Toast', type:'poptart' }
> >         ]
> >         },
> >         { name:'Chocolate', type: 'category'}
> >     ]
> > }
> >
> > Where the only important stuff here is that child nodes should be put in a
> > separate array [], not as an object  to the parent node, like this;
>
> ...(snipped current format)
>
> Ok, so basically you'd like the child nodes to be in an array named 
> "children".
>
> I know others on this list have more javascript experience than me,
> what do people think?
>
> > ....Also, I have difficulties understanding what to do with the
> >
> > "testing":
> >            {"jcr:primaryType":"nt:unstructured",
> >
> > part, since I would somehow like it to be like this;
> >
> > children:
> > [
> >           {
> >                   title: 'testing',
> >                   jcr_primaryType: 'nt:unstructured',
> >                   children:
> >                   [
> >                               { title:"test2", sling_resourceType:
> > "usling/example", jcr_primaryType: "nt:unstructured", text: "Default text of
> > the test node"},
> >                                ....
> >                   ]
> >           }
> > ]
> >
> > Hmm. I really think that this would be the correct translation, now that
> > I've printed it out. The problem was in choosing how to remove the current
> > "name: {}" structure to move the name into the object (where it is anyway),
> > like children: [{title: name....}]...
>
> Ok, I agree that the above is more immediately understandable than the
> current format.
>
> The downside, iiuc, is that if forces the use of ".children." to
> access children...well, not sure if that's a downside, let's hear what
> other javascript aficionados think!
>
> > ...Note that children is just a convenient name, and doesn't mean anything
> > magic. Also, I would feel very much more comfortable not having quotes
> > around property names. I understand that they're there to escape the ':' ,
> > which are very magic in js and separates property names from values,
> > therefore I replaced them with underscores....
>
> IIUC, the goal with removing the quotes is only to make the JSON look
> nicer, is that right?
>
> The problem with transforming sling:resourceType to sling_resourceType
> in JSON is the possible confusion in documentation and in people's
> minds...I don't like that too much.
>
> As you indicate, making other JSON renditions pluggable would be easy,
> but I think we should be able to agree on a good enough default
> format.
>
> -Bertrand
>

Reply via email to