And, yes, that's also what I'm thinking. It doesn't matter in json what the contents of a string is, as long as it doesn't mess with the json structure itself (which it can do now).
The 'meaning' of a property value is application domain specific anyway, so I think we can choose any encoding type which is reasonably simple, as long as it is documented clearly. Cheers, PS On Jan 22, 2008 11:46 AM, David Nuescheler <[EMAIL PROTECTED]> wrote: > > > ...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... > > That can be done on the client, sure, but I think we should support > > some useful cases on the server side. > it depends on the client lib that you are using. some js client libs > require urls to pull their data from, then we are locked into doing that > on the server. > > > > ... from a url perspective something like ... > > > > > > /mynode.all.0.json > > > /mynode.all.1.json > > > > > > ... or ... > > > > > > /mynode.dojotree.infinity.json > > > > > > could do the trick... > > Agreed, the convention would then be to use the last selector > > (0,1,infinity) for the recursion level, and the selector before that > > for the JSON "flavor". > given our current resolving i think we actually can leave this open. > right? > > if i assume that i have the following setup. > > .../json.servlet (which handles everything that is not mapped) > .../dojotree/json.esp (woudl deal with the server sided conversion) > > wouldn't that be natural? it is then up to the dojotree/json.esp to worry > about the additional parameters... right? > > > Currently the default renderers are hardcoded in the > > launchpad-servlets module, but we'll need to make them pluggable at > > some point anyway, so implementing what you suggest shouldn't be a > > problem. > i see ;) > > regards, > david >
