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]
