> At 06:01 PM 1/20/2006, Rasmus Lerdorf wrote: > >Andi Gutmans wrote: > >>Yeah, but the main problem with this kind of stuff is when > you start > >>mapping classes and even references. I think it requires some > >>additional pluming to be really useful for writing robust > >>JavaScript<-->PHP connectivity so that it's flexible enough for all > >>those PHP packages to start using it. > >>I'm +1 for including JSON but not on the way the API is > defined right now. > > > >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? > > Yes exactly. So for example, we should define some special > string/value pair that conveys the class of the object (e.g. > __classname:MyClass). I'd say that this is almost critical to > allow a very nice mapping between the client side Javascript > and the PHP layer. This way you can pretty much do a 1:1 > mapping from Javascript objects (which might be nested) to > PHP objects. The decode() would just find this __classname > and make sure to instantiate MyClass and put the key/value > pairs in that.
What are the security implications of doing this? Creating objects based on a string from a untrusted source seems not good idea, unless can prevent tampering (with an HMAC or something). Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
