OK, let's put a JSON library in the LFC. I'll file an improvement to look at the one Sebastian sent and see how the performance/compliance compares with the one we're using..
On Fri, Apr 10, 2009 at 10:14 AM, P T Withington <[email protected]> wrote: > What I am trying to say is: > > Javascript is going to include JSON > > We should make sure our JSON implementation conforms to the proposed > standard > > We should export that at the LZX API so LZX programmers can use it > > [As a bonus, some browsers will surely implement the ES5 standard > incrementally. When the browser supports JSON natively, we should use that, > rather than our Javascript implementation, as it will clearly be faster.] > > > > On 2009-04-10, at 10:02EDT, Henry Minsky wrote: > > 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] >> > > -- Henry Minsky Software Architect [email protected]
