For the rpc library, on the Laszlo client side, for all runtimes, I used an implementation of JSON (lps/components/rpc/library/json.js) that Oliver wrote. For the DHTML runtime, I decided not to use the native DHTML 'eval' , even though it would probably be faster, because I wanted to have a consistent implementation across all runtimes, and also eval() is kind of scary from a security point of view.
On Fri, Apr 10, 2009 at 9:52 AM, Sebastian Wagner <[email protected]>wrote: > yes thats right. The class that does it is: > org.openlaszlo.remote.json.LZReturnObject > > This class uses at the moment a custom marshalling to transfer > Java-Objects to JSON. > The question would be to replace the custom marshalling of > LZReturnObject with JSONTools ... or in other words how conform is the > JSON that LZReturnObject produces compared to the one that the various > JSON Libraries produce. I could imagine that there are some tricks to > JSON-Structure to fit into the Data-Structure that the > OpenLaszlo-Client expects. > > sebastian > > 2009/4/10 P T Withington <[email protected]>: > > I thought it was already used to send data "over the wire" to the client > and > > then is parsed into XML on the client side? > > > > On 2009-04-10, at 09:08EDT, Sebastian Wagner wrote: > > > >> will this also have an effect to the way data is send to the Client? > >> > >> one possible library we could piggy back is > http://jsontools.berlios.de/ > >> > >> > >> sebastian > >> > >> 2009/4/10 P T Withington <[email protected]>: > >>> > >>> Will be a part of the forthcoming ECMAScript 5 standard. I suspect it > >>> will > >>> be available in early forms in many of the browsers. I thought you > were > >>> already using it in the LFC, so maybe we should export it at the API so > >>> it > >>> is generally available for LZX? It looks like Lorien (cc-ed) might be > >>> able > >>> to use it. > >>> > >>> I believe the main bits are: > >>> > >>> JSON.stringify which takes an Object and produces a string, and > >>> JSON.parse > >>> which takes a string and produces an Object (similar to the one that > was > >>> stringified). > >>> > >>> The built-in data types each have a method .toJSON that can be > >>> overridden, > >>> and stringify and parse each take an optional filter function that can > be > >>> used to restrict or extend the encoding. > >>> > >>> There is probably an open source implementation of the proposed > standard > >>> that we could grab for runtimes that do not yet have it built in. > Check > >>> out > >>> http://json.org. > >>> > >> > >> > >> > >> -- > >> Sebastian Wagner > >> http://www.webbase-design.de > >> http://openmeetings.googlecode.com > >> http://www.laszlo-forum.de > >> [email protected] > > > > > > > > -- > Sebastian Wagner > http://www.webbase-design.de > http://openmeetings.googlecode.com > http://www.laszlo-forum.de > [email protected] > -- Henry Minsky Software Architect [email protected]
