Re: [PHP-DEV] JSON inclusion in core
Alan Knowles
with objects etc), doing standard HTTP GET/POST requests with urlencoded
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..
Regards
Alan
Douglas Crockford wrote:
>>I guess I am confused.
>>Javascript, and thus JSON, has no concept of an object.
>>It has something it calls an object, but that is just an
>>associative array.
>>Are you trying to layer some other syntax on top of
>>JSON to convey more meaning than what JSON/Javascript
>>natively supports?
>>
>>
>
>JavaScript does have a concept of an object in its prototype chain.
>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
Rasmus Lerdorf
> 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 urlencoded
> 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..
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
this point.
-Rasmus
Daniel Convissor
>
> A "working" strip_tags, something like strip_tags_ex :)
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.
Pardon,
--Dan
--
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
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Jim Plush
built into PHP will bring JSON usage to the forefront of "AJAX"
development.
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.
Paul
> "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
>=20
> 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
Douglas Crockford
> >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.
> 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
> urlencoded
> 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.
Rasmus Lerdorf
> Здравствуйте, internals.
>
>> "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
>>
>> 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.
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.
-Rasmus