I started playing a bit with an OOPHM client (for GWT-in-the-AIR). I lloked a bit at the code and thought I could inherit BrowserChannel to benefit from the *Message nested classes and the reactToMessages* methods.
First, I wanted to know what kind of messages were exchanged, so my BrowserChannel impl (or, actually SessionHandler impl) just prints out the received messages and eventually sends back a ReturnMessage with "undefined" value (new Value()). That's an approach that could very-well be used for unit-testing the OOPHM server-side impl code (AFAIK, there's no test harness for OophmBrowserChannel, OophmSessionHandler et al.). First thing to notice: it just doesn't work, for 3 reasons: 1. LoadJsniMessage::receive() calls stream.readUTF() instead of BrowserChannel::readUTF(); that's a very small bug and was easy to fix. 2. Much more of a "design mistake" (IMO) is that InvokeMessage is asymmetric: InvokeMessage::send() sends a "method dispatch ID" while InvokeMessage::receive() expects a "method name". This means InvokeMessage (hence BrowserChannel) cannot be used as-is for client- side OOPHM. 3. the reactToMessages* methods are server-side oriented (for instance, they don't react to LoadJsni messages) So I started "patching" branches/oophm: - split InvokeMessage into InvokeByDispatchIdMessage and InvokeByNameMessage (could also have instead added a boolean to InvokeMessage serialization to tell whether it's a by-dispatch-id or by-name message) - added an invoke() method to SessionHandler with a "method name" argument instead of the "method dispatch ID" (implemented as a "throw new UnsupportedOperationException()" in OophmSessionHandler) - added a loadJsni method to SessionHandler (UnsupportedOperationException in OophmSessionHandler) and added LoadJsniMessage handling to reactToMessages* methods. These changes (maybe others are needed though) make BrowserChannel usable both as a client and server, so you can write an OOPHM client in Java. But maybe it'd be better to have a ServerBrowserChannel and ClientBrowserChannel with distinct reactToMessages* implementations (InvokeMessage would still have to be changed though, to accept receive()ing a "by name" message and send()ing "by dispatch id" messages). What do you guys think about it? (first the idea of using BrowserChannel as the basis to implement an OOPHM client, and then the proposed changes to BrowserChannel to make it possible) --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
