Is JSONParser() also unsafe?It also does an eval() without inspecting the string. So, yes, it is also unsafe.
From the JSONParser() code, I get the impression that it tries to differentiate among arrays, strings, &c. I thought that such behavior was A Good Thing.Not as good as a Javascript overlay. When you get a rich, domain-specific object that is also performant, why would you want generics like an arrays and strings?
Hi Thomas:On 01/04/2010 10:57 AM, Thomas Broyer wrote:
>
> On Jan 4, 4:01 pm, Jeff Chimene <jchim...@gmail.com> wrote:
>>
>> I have a question:
>> <snip>
>>
>>> *Performance*
>>
>>> - Client Side - REST with JSON wins over RPC. Browsers are
>>> exceptionally good at json parsing. It is going to be much faster than GWTs
>>> serialization/deserialization mechanism. This is applicable only if you use
>>> javascript overlays. JSONArray/JSONObject/JSONValue classes don't give you
>>> this performance benefit.
>>
>> I've been using the following technique to use the JSON parsing in 2.0. I
>> don't see a specific example in the docs:
>>
>> Report.set(JSONParser.parse(response.getText()).isObject().getJavaScriptObj ect());
>>
>> Where Report is defined as follows:
>>
>> public class Report extends JavaScriptObject {
>>
>> protected Report() {}
>>
>> public final static native Report get() /*-{
>> return $wnd.Report;
>> }-*/;
>>
>> public final static native void set(JavaScriptObject value) /*-{
>> $wnd.Report = value;
>> }-*/;
>>
>> }
>>
>> I don't see any other way to avoid unsafe parsing.
>>
>> Comments?
>
> Use JsonUtils.unsafeEval() to avoid the unused JSONObject created by
> JSONParser.parse(), and then just use .cast() to turn the JSO into a
> Report (unless of course you want a singleton in the $wnd.Report
> global JS variable):
>
> Report myReport = JsonUtils.unsafeEval(response.getText()).cast();
Isn't an aspect of unsafeEval() that it's unsafe? Is JSONParser() also
unsafe? Or do I always want to add comments to the cargo at the
generator, strip such comments at the receiver and call unsafeEval() (&
its equivalent on the server)
From the JSONParser() code, I get the impression that it tries to
differentiate among arrays, strings, &c. I thought that such behavior
was A Good Thing.
>
> --
>
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
On 01/04/2010 03:02 PM, Sripathi Krishnan wrote:
> New subject -- we have diverged from the original post.
>
>
> Is JSONParser() also unsafe?
>
> It also does an eval() without inspecting the string. So, yes, it is
> also unsafe.
> If you are unsure about the safety of your input string, then you should
> employ techniques before you invoke JSONUtils or JSONParser. See this
> discussion thread
> <http://groups.google.com/group/google-web-toolkit/browse_thread/thread/7dfac0233a98c5eb>.
Good reference.
> From the JSONParser() code, I get the impression that it tries to
> differentiate among arrays, strings, &c. I thought that such
> behavior was A Good Thing.
>
> Not as good as a Javascript overlay. When you get a rich,
> domain-specific object that is also performant, why would you want
> generics like an arrays and strings?
From 30K ft., it looked like there was some validation of the JavaScript
object, in the sense that if I expect an array, then the isArray() test
fails at runtime.
Nevertheless, the gwt-rpc-plus looks interesting.
Sadly, since last time we spoke, my one chance to move to GWT from Perl
has evaporated. So, it's back to Perl until the wheel spins round and I
get another chance to move some of this one app's Perl code to GWT.