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
-~----------~----~----~----~------~----~------~--~---

Reply via email to