Re: [PHP-DEV] JSON inclusion in core

5 views
Skip to first unread message

Alan Knowles

unread,
Jan 23, 2006, 9:03:44 PM1/23/06
to
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..

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

unread,
Jan 23, 2006, 11:16:05 PM1/23/06
to
Alan Knowles wrote:
> 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

unread,
Jan 24, 2006, 1:02:10 PM1/24/06
to
On Mon, Jan 23, 2006 at 06:00:24PM +0100, Pierre wrote:
>
> 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

unread,
Jan 26, 2006, 5:17:58 PM1/26/06
to
From the enterprise point of view I think having the JSON extension
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

unread,
Jan 30, 2006, 9:46:00 PM1/30/06
to
=C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, 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
>=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

unread,
Jan 31, 2006, 10:24:28 AM1/31/06
to
> >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.

> 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

unread,
Jan 31, 2006, 11:54:31 PM1/31/06
to
Paul wrote:
> Здравствуйте, 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
>>
>> 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.

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

Reply all
Reply to author
Forward
0 new messages