Hi, I don't know enough about system particulars to recommend what to do, but from a 'user' perspective, it would have been great to be able to have several kinds of json renderings, to provide for different libraries. I bet that YUI and Ext have different choices, for instance.
My first idea, was to write a short esp script, which accessed the node info and which generated a structure based on that. It would be shorter that the requisite Java render by (probably) an order of magnitudes, and would be very easy to extend or modify. But that is where I got stuck, since I don't understand Sling so well yet. It should be workable, but since things are in flux right now, I get easily confused :) Maybe I should try to generate my own Sling start.jar from the svn i checked out last night, and see if I can insert an esp script at some point. Cheers, PS On Jan 22, 2008 11:04 AM, David Nuescheler <[EMAIL PROTECTED]> wrote: > 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 > > >
