Thinking further, I think it's better to separate the EventBus from the Command system somewhat. The reason being that generally, events are used to update on changes that have already happened, or are about to happen. They don't trigger the actual event itself.
For example, you have a 'CreateUserEvent'. This is sent out and three listeners pick it up. There is no way to control the order the handlers are sent the event, so one might actually create the user, and the others expect it to already be created. You'll have issues at that point. Also, what happens if the creation fails? Should the event keep propogating, or stop? It's also more difficult to provide feedback to the original creator if there were problems. Yes, it could send out another event over the bus, but then you end up with custom 'error' events all over the place... Anyway, I've ended up implementing them separately. In fact, they are completely decoupled from each other - so much so that I've got two separate projects for them: Command Pattern API: http://code.google.com/p/gwt-dispatch Presenter Pattern API: http://code.google.com/p/gwt-presenter The latter is 'fresher', meaning it's subject to change. gwt-dispatch is pretty solid now - I'll be releasing 1.0 shortly. Have a look and let me know what you think. David On Jul 15, 2:46 am, "Alejandro D. Garin" <[email protected]> wrote: > I forget to post the link: > > http://puntosoft2k.appspot.com/Showcase.html#ContactWidgetEventBus > > Thanks. > > On Tue, Jul 14, 2009 at 1:43 PM, Alejandro D. Garin <[email protected]>wrote: > > > 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 > > <[email protected]>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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
