Casting from raw JS to GWT class

[Allyn]

We have the following setup:

Two GWT-based web pages, built separately but hosted on the same web
server and used side-by-side in iframes in the same browser window/
tab. The two web pages both include a common module that defines
common data model objects (i.e.POJOs). Instances of these objects are
sent from one of the pages to the other via JavaScript.

While each projects is using the same shared GWT module for the common
data model classes, each appears to use different class IDs behind the
scenes when GWT builds it into JavaScript for each web page project.
These IDs are what are used to map from raw JS objects to the GWT
classes. Unfortunately, since each project is creating different IDs
for the same classes, it cannot properly cast an instance of a class
received from the other web page.

Is there any way to compile the common module once and include the
compiled JavaScript in both other projects, rather than including the
raw Java code and compiling it two different times, to ensure that the
class template mapping metadata is the same across web pages?

I realize this is an odd (and probably not recommended) setup, but it
is a requirement from the customer for reasons I won't go into here.

[Jamie]

I don't think you can do that... bringing in a common pre-compiled-js
module. That would be pretty cool.

If your two sites are not that big, then you could compile them into
one app, and then decide which widget(s) to show based on the URL in
the onModuleLoad.

Or perhaps you could try communicating between the modules using JSON,
with the built-in GWT JSON library.

[Allyn]

Unfortunately both projects are fairly sizable and it would not be ideal to merge the projects. It would create a lot of additional overhead maintaining the code separately especially since the release cycles are not in sync. I would rather do what we're currently doing to work around this...manually parsing the object's data as primitives when going through the raw JS channels. It's just that there are a LOT of separate messages that need to be individually parsed out separately rather than just being able to cast the message back to the formal event objects we defined.

[Allyn]

After some thought I think I am going to try to see if I can use the raw JS message to identify what the class name should be (or, if necessary, send the class name as a string separately). Then I should be able to create an instance of the desired class on the destination side and get its ID on that side from there. The tricky part will be forcing the object, still as a raw JS string at this point, to cast using this ID on the destination side instead of the original class ID from the source side.

[Thomas Broyer]

IMO, you should pass JavaScriptObjects around, that way you totally control how they look like, so they can be safely exchanged.

From one of the GWT apps, you shouldn't see your other app as another *GWT* app, it's just another *JS* app.

[Allyn]

You know, I actually tend to agree with you on this in general Thomas. The reason I'm looking for the kind of solution I am is that due to the design and the requirements from the customer, this is never expected to be run outside this configurations/environment (it will actually depend on it for other reasons). So, because of that, a way to cast the raw JavaScriptObject back to a "GWT known class" would provide a much simpler way for my developers to pass data between the apps.