JSON in general looks far better suited to the PHP->js layer..
Douglas Crockford wrote:
>>I guess I am confused.
>>It has something it calls an object, but that is just an
>>Are you trying to layer some other syntax on top of
>However, it is not captured in JSON, so the part about JSON's object
>being just an associative array is correct.
>It makes sense to me that JSON->PHP would produce an associate array.
>Independent of that, it might be convenient to have a tool that maps
>associative arrays into objects, but that is not a JSON operation.
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yup, until browsers start sending JSON requests natively, I don't see
much js->PHP usage either. PHP->js is the much more common use case at
Ah. My brain was still on the JSON part of this thread and was befuttled
by Rasmus talking about tags and attributes in relation to JSON.
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
I've been using Omar's extension here at McAfee with great success
lately... rolling out rich UI app prototypes. Shared Host users without
access to extensions will miss the boat and have to rely on user space
JSON classes which are much slower.
> "From: Rasmus Lerdorf
> To: inte...@lists.php.net
> CC: om...@rmilk.com
> Subject: [PHP-DEV] JSON inclusion in core
> Date: Fri, 20 Jan 2006 11:31:58 -0800
> pecl/json is a rather simple extension with no external deps (it
> bundles the small library it uses). The JSON format is stable with
> no real possibility of changing basically by definition, and I see
> its use exploding this year. There is also talk to a JSON Request
> object being added to browsers and if that happens we need to
> support that natively much like we support url-encoded form data
> ending up directly in $_POST. I could see a $_JSON if browsers
> start sending this. But, as an initial step how about we bundle
> pecl/json in the next release?
I think super-global array $_JSON is a bad idea, because it allows
only single instance. It is not $_GET or $_POST which are always
single per request.
Also, $_SESSION was bad idea too, when we need 2 separated sessions
(for example with different cookie params) - we cant use PHP
integrated session solution.
So please, do not repeat old mistakes.
Regards, Paul mailto:gugg...@gmail.com
> I'm not sure that js->PHP is that critical (in terms of
> getting clever
> with objects etc), doing standard HTTP GET/POST requests with
> values into $_GET/$_POST, 99% of the time is far more
> efficient way of
> sending data to the server, and alot easier to debug.. You can also
> implement the filter code on that data....
> JSON in general looks far better suited to the PHP->js layer..
That is true at the moment. I am expecting that to change. In any case,
it makes sense that you can go in either direction.
You are confused. $_JSON would be for the JSON request mechanism that
is being discussed. By definition there can only be 1 JSON body per
JSON request, just like there can only be 1 POST body per POST request.