json api design issues

[Jesse Kuhnert <jk...@gmail.com>]

Jun Tsai has brought up some good points about the current JSON support in
Tapestry here http://issues.apache.org/jira/browse/TAPESTRY-1053.

I still haven't quite figured out all the ins/outs but I'm starting to think
along the lines of optionally allowing people to return an object from the
existing IJSONRender interface . (Looks like renderComponent, only it passes
in a writer with JSON semantics instead of markup ).

So...Really, JSON output can be one (and only one) of either two structures
- An array or an object. Either can of course contain nested variations of
anything concievable.

Does looking for a JSONArray (or something similar to it hidden behind an
interface) in the render call return - similar to how listener methods may
optionally return an ILink/Page/String of page name/etc sound like a
somewhat ok idea?

This one is definitely very high up there on the list of things that must be
designed correctly, but I can only hit the boundaries of the api with real
world usage. Like what Jun Tsai found :)

It's barely a passing design thought, really haven't invested the amount of
time into it to think it all through clearly but thought I'd try and make
other people think about it too in case others have more "requirements" I
don't know about.

-- 
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: json api design issues

[an...@di.uoa.gr]

Do you then see JSONObject and JSONArray sharing a common superinterface?

Either way, arrays and hashes are going to be needed at the client and so,
unless ['a','b'] === {0:'a',1:'b'} indeed works,
I don't see why we shouldn't allow both.

BTW, sharing a superinterface would allow a method to decide at runtime
what to return... This may have also been useful in the ILink/Page case. 

>From Jesse Kuhnert <jk...@gmail.com>:

> Jun Tsai has brought up some good points about the current JSON support in
> Tapestry here http://issues.apache.org/jira/browse/TAPESTRY-1053.
> 
> I still haven't quite figured out all the ins/outs but I'm starting to think
> along the lines of optionally allowing people to return an object from the
> existing IJSONRender interface . (Looks like renderComponent, only it passes
> in a writer with JSON semantics instead of markup ).
> 
> So...Really, JSON output can be one (and only one) of either two structures
> - An array or an object. Either can of course contain nested variations of
> anything concievable.
> 
> Does looking for a JSONArray (or something similar to it hidden behind an
> interface) in the render call return - similar to how listener methods may
> optionally return an ILink/Page/String of page name/etc sound like a
> somewhat ok idea?
> 
> This one is definitely very high up there on the list of things that must be
> designed correctly, but I can only hit the boundaries of the api with real
> world usage. Like what Jun Tsai found :)
> 
> It's barely a passing design thought, really haven't invested the amount of
> time into it to think it all through clearly but thought I'd try and make
> other people think about it too in case others have more "requirements" I
> don't know about.
> 
> -- 
> Jesse Kuhnert
> Tapestry/Dojo/(and a dash of TestNG), team member/developer
> 
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
> 


-- 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org