Monday, September 24, 2012

Re: Way get info if JavaScriptObject is one of defined overlay objects



On Monday, September 24, 2012 2:24:50 PM UTC+2, js402882 wrote:
> You don't have a notion of "type" on your created objects, so you won't have that in Java either. I mean, in JS, with the same factory, how would you tell if you have a > "table" or a "car"? if you had constructor functions for the objects (new Table, new Car), you could do instanceof checks (in JS). Or you could have a "type" property > on your objects, so you could getType() in Java to do conditional processing. 

First of all thanks for reply.

I understand that. 
My problem is that I don't know what object is created in native code. Maybe I oversimplified my real use case in the name of clarity. 
What I want to do is JSON RPC client for GWT. The aim is provide simple API which will only require the user to define return types as JSO overlays and definition of remote interface. In other words API should be as near as possible to the GWT RPC.

Have a look at gwtjsonrpc: https://gerrit.googlesource.com/gwtjsonrpc/ (browser source: https://gerrit.googlesource.com/gwtjsonrpc/+/master/ changes: https://gerrit.googlesource.com/gwtjsonrpc/+/master )
Binaries can be found at https://gerrit-maven-repository.googlecode.com/svn/
Real-use: https://gerrit-review.googlesource.com/ (source code: https://gerrit.googlesource.com/gerrit/+/master/ )
 
That said I don't know (in native code) of what type the created object is:

Because it's probably only an "Object" with "expando" properties. The correct question would be whether the structure of the object is correct (provided it's an Object and not an Array, String, Boolean or Number)
 
  - good case is that it's correct JSON object which has defined JSO overlay; 
  - bad case is that it's something else (string, wrong/unexpected JSON object, ...), in that case I need to generate meaningful error

What I need to solve is how to know that response is wrong. Now, only solution I see is some sort of JSON schema validation in native code - this would work, but it would require additional work from user of API (define schema of good response). But that's I want to avoid.

If you have better idea and willing to share, please do :)

The only 2 reasons you'd have a mismatch would be:
  • the user used an incorrect return type for the method: he can only blame himself.
  • the service has changed in incompatible ways: blame the service owner, he's an asshole.
I'd suggest you don't add unnecessary logic to your code: only deal with Object vs. Array vs. String vs. Number vs. Boolean (the only 5 data types in JSON, besides 'null'). It could be great that you provide JSON-Schema validation but it should IMO be optional.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Q-6F_X8ROiIJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

No comments:

Post a Comment