Hi, I wrote an implementation (first try) based on the Command Pattern and EventBus described in the Ray Google IO Talk. (what I understand from the slides). The working example is trivial but the code uses an event bus (using gwt HandleManager) and the command pattern for the RPC Service.
Comments are welcome, I would like to know if the implementation is good. Thanks, On Mon, Jul 13, 2009 at 10:31 PM, David Peterson <da...@randombits.org>wrote: > > There's certainly nothing to stop you, and you could even just add > your own RPC Event and have a listener trigger the server-side call. > In fact, in my own implementation of Ray's example (http:// > code.google.com/p/gwt-dispatch), the Action and Response are both > interfaces, so you could just have the base class be a GwtEvent > subclass. > > The main complication I guess is the server side. I haven't tested to > see if you can just use a custom EventHandler server-side without > changes, but I'm guessing it would work fine. > > David > > > On Jul 11, 4:41 pm, Kwhit <kwhitting...@gmail.com> wrote: > > Just throwing up an idea here to see how many bullet holes it comes > > down with. > > > > I'm playing around with the command pattern which is a hot topic at > > the moment and wondered why it shouldn't be merged with the EventBus? > > The command pattern proposed by RR has to add a response object - the > > original doesn't (I don't have a GoF copy to hand), using and event > > bus would remove the requirement for it. > > > > Using the example presented by RR. > > > > 1/ User clicks on 'save' to save the edited phone number > > > > 2/ Presenter creates an RpcCommandEvent{<save>, <new phone number>} > > and fires it to the eventBus > > > > 3/ RpcPipe, listening for RpcCommandEvent events, ships them off the > > to the server > > > > --- Server side --- > > > > 4/ RpcPipeService receives the event and invokes a specialized handler > > > > 5/ The handler verifies (for the sake of the example but I would > > normally do this client side) the new phone number, finds it OK and > > updates the storage > > > > 6/ Handler returns new phone number for contact ID x > > > > 7/ RpcPipeService ships (returns) the response on across the pipe > > > > --- Back on the client side --- > > > > 8/ RpcPipe fires the RPC return value as an event on the bus > > > > 9/ Listeners to ContactInfoUpdated events update the phone number > > > > I, in my ignorance, find the above a net gain > > > > * +ve: One pipe fits all, no need to update the mechanics of the RPC > > * +ve, -ve: The event designer has to know that the event should be > > shipped over the pipe > > * +ve: The statefulness of the RPC mechanism (every request has a > > response) fades away > > * +ve: In fact the Pipe itself could disappear with a bus on the > > server (see below) - end to end unit testing > > > > In my event driven fever I would also like to have an event bus on the > > server so that the handlers could register themselves for events but I > > not worried too much about that yet. > > > > OK fire away! > > > --~--~---------~--~----~------------~-------~--~----~ 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-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---