Way get info if JavaScriptObject is one of defined overlay objects

[js402882]

Is there any way get info if JavaScriptObject is one of defined overlay objects? 

Example:

I have native factory method which creates JavaScriptObjects:

class WeirdFactory

{

    native JavaScriptObject create(String type)

    {

        if (type == "car") return { name: "e46", maker: "bmw", seats: "4"}

        else if (type == "table") return { material: "wood", color: "brown"}

        else if (type == "type i forgot to crate overlay object for") return { id: "someId", name: "someName" }

        return null;

    }

}

class Car extends JavaScriptObject

{

    native String name() /*-{ return this.name; }-*/;

    native String maker() /*-{ return this.maker; }-*/; 

    native int seats() /*-{ return this.seats; }-*/; 

}

class Table extends JavaScriptObject

{

    native String material() /*-{ return this.material; }-*/;

    native String color() /*-{ return this.color; }-*/; 

}

Now I want to use this factory to create overlay objects:

<T> void getValue(Class<T> returnType, Callback<T> callback, String type)

{

    JavaScriptObject value = weirdFactory.create(type);

    // Here I need something like

    // if (!JavaScriptObject.isDefined(value))

    // {

    //     handleUndefinedJSO(value); // or throw new IllegalArgumentException("Undefined overlay object")

    // }

    

    T returnValue = (T)value;

    callback.returned(returnValue)

}

I need somehow check if value JavaScriptObject has defined custom overlay object (... extends JavaScriptObject)

In pure Java I would catch ClassCastExcetion. But this does not work with JavaScriptObject which simply casts to anything (from it's nature, it's JavaScript object in the end after compilation).

Does anybody have idea how to get info if JavaScriptObject is one of defined overlay objects? 

regards

js

[Thomas Broyer]

There's nothing like "defined overlays for a given JS object". Overlays are only a Java API to access a native JS object.

For instance, "Car car = weirdFactory.create("table")" is perfectly legal, and car's getters will simply return null/undefined. And then you can do "Table table = car.cast()".

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.

[js402882]

> 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. That said I don't know (in native code) of what type the created object is:

  - 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 :)

[Thomas Broyer]

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.