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 <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
