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 <aga...@gmail.com>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 <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
-~----------~----~----~----~------~----~------~--~---
