This is the regexp that the JSON RFC suggests:
var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
eval('(' + text + ')');
It will take me awhile to digest how it actually works :), but
assuming that it does work, it would provide a safe and efficient way
to validate JSON before evals, atleast until browsers provide native
JSON parsers.
I must say that as a GWT developer, a generic JSON library doesn't
appeal to me very much except in rare cases where you're trying to
deal with arbitrary JSON from unknown sources, say, if you were
writing a JSON-as-GWT tree visualization.
But for most service interaction, you have to know the schema/format
of the service you are dealing with upfront, so if I'm building a
mashup, I prefer to just build concrete overlay types for each
service. The compiler is helped by this as well.
I'm not against DSLs, one of the things I'm working on is a
Microformat equivalent to my GWT Exporter which allows you to take a
POJO and "map" it to an HTML Microformat structure for
serialization/derserialization, and this is done by both convention
and configuration (i.e. with annotations) There are proposals for
things like JSONPath, an XPath equivalent, but again, this totally
obscures object type relationships in the JSON object.
I'm much prefer a DSL that somehow taught the compiler what it was
navigating. If the .proto format is too obscure, you could go in the
reverse direction. Code up a POJO or interface, and use a generator to
turn the interface/POJO into a .proto file, and a linker to invoke PB
and package up a bunch of server-side deployables for whichever
container/language environment you like. This would keep everything in
Java.
Barring that, as Scott mentioned, you could use something like my
gwtquery approach to combine JSON queries into inlined code.
I'm doing alot of work right now integrating GWT JSOs with Google
AppEngine JSON services, and having a fast, efficient, easy to use,
and secure JSON library it pretty important. I'm not against a generic
parser, but something that could lighten the load for those using JSOs
to integrate with non-Java server environments would be a big win. As
cool as GWT RPC is, it's not a universal hammer.
-Ray
On Thu, Aug 28, 2008 at 1:39 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> Reinier, I have to agree that a single library that could be used client and
> server side would be really useful, particularly if you use some
> GWT.isScript() love to make the client side really efficient. And it sounds
> better than the current JSON library (not that that's saying a lot).
> A few random thoughts:
> - You'd have to be pretty careful about how the API is constructed to get
> all the dead stripping. Example: if .toObject() is allowed to return Date,
> you've basically pulled in all the date parsing code.
> - I have been told that there are some regexps available which allow you to
> accept or reject input as legal JSON. You might look into this as a really
> fast way of doing safe parse. Along those lines, we regret that our JSON
> library's "parse" is the unsafe version. I would strongly consider having
> an 'unsafeParse' (and possibly not having a method named 'parse' at all.
> - The "foo/bar/1" stuff kinda makes my stomach turn, honestly, contrast with
> Ray's gquery compile-time evaluation. I know j.get("foo").get("bar").get(1)
> is more verby, but at least in theory that can be optimized/inlined.
> Although, who knows, the compiler does do static string eval these days, so
> maybe if you're extraordinarily clever about the implementation, you could
> get static eval to work in your favor.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
