Thanks for the reply I have some further thoughts... Looking at the source code for the event handling in GWT 1.6 it seems the fundamental difference is as follows...
Old way with listeners "I am adding this event listener to this component, when the listener is triggered I know the source must be this component as it is the only one added to the listener list" New way with listeners "I am adding this handler to this component, when something happens to the component firing and event I will receive a notification, the event itself will contain enough information such as the source or custom properties which let me determine how to do something." The more I think about the architecture outlined by the tech talk the smarter it seems. For example by using this event driven application you can swap out the UI much easier. Instead of having a button run an RPC which on result runs code that that one component you have a button trigger an RPC request which fires back to a central event handler which then notifies all interested parties regardless of which component initiated the request. When swapping out the UI for browsers to an iPhone specific version it would be much much easier to just have the exact same handlers and events but swap out the components which render things to the display. In my readings last night I discovered another term for what is outlined in the "EventBus" idea was coined by Martin Fowler as "Event Collaboration" http://martinfowler.com/eaaDev/EventCollaboration.html. In the video at 27:3# Ray Ryan shows some MVP code which seems to tie in with this it uses methods like "HasClickHandlers" to define the interface for the UI. Does anybody know if this is typical of MVP or a flavour cooked up by Google? I am having a hard time finding quality resources describing MVP in the sort of context appropriate to GWT. On Jun 12, 7:39 am, Thomas Broyer <[email protected]> wrote: > On 11 juin, 21:34, Benju <[email protected]> wrote: > > > I did not attend Google I/O but as soon as the video "Google I/O 2009 > > - Best Practices for Architecting GWT App" (http://www.youtube.com/ > > watch?v=PDuhR18-EdM) was posted I reviewed it and was a bit confused > > by the idea of an EventBus. > > For my part, I was pleased to see it as a best practice, as that's > what I'm thinking about for nearly a year (would require a huuuuuuge > refactoring of our app, so it's still "just an idea floating in the > air") > (I didn't watch the video, just looked at the slides) > > > From what I can tell the idea is that UI widgets requiring data from > > the server are able to fire off requests for some form of data like > > "void getTransactionsForAccount(Account acct)" then at some unknown > > later time (ms to seconds ussually) when a response comes in from the > > RPC call the eventbus is what actually directly recives the data and > > then it is dispatched > > Well, not necessarily, though yes, that's what they said at Google I/ > O. One of the reasons is that there are probably more than a single > place where you use that same data in your app (in GMail it could be > the list of mails, the unread count for the "box" and/or label(s), and > the conversation view of course). That way, all places are informed, > wherever the initial request came from. > > > > > Client UI: "Hey call some RPC method with these parameters, my > > AsyncCallback is this EventBus thing" > > > ...some unknown time passes while the server does magic... > > > Client Event Bus: "A response came in of type X/Y/Z I should fire an > > event to all interested parties" > > > Client UI: "According to this event I just recieved some of my UI code > > needs to change" > > > A few things are still very hazy for me... > > > 1- What is missing here is when would the Client UI typically > > subscribe/unsubscribe from the event bus. If this were a desktop > > application I would simply use weak reference so I would not have to > > unsubscribe my UI manually to prevent a memory leak. > > As with any event, I'd subscribe in the onLoad and unsubscribe in the > onUnload (would be even better if there was a destructor, so that even > when not attached to the DOM, your widget could receive events and > enter a "dirty" state, so that when it is attached again to the DOM it > knows if it has to refresh or not) > > > 2- Is there some EventBus code I should be using that already exists > > in the GWT SDK? Is this the same code that is used for handling > > widget events like clicking a button? > > Wasn't the code shown in the slides? (page #73 in the PDF, the event > bus is just a HandlerManager (GWT 1.6 and upwards)) > > > 3- Would you typically have one eventbus code for everything? > > If your event bus is just a HandleManager as in the presentation's > sample code, then yes. > > You would probably have one event bus (instance) for the whole app, > but you could also use some kind of HMVC (HMVP?) with "component-wide" > event buses. > (I'd rather have a single event bus though, and just use "component- > specific" events) > > > 4- How does this tie in with the MVP pattern? > > slide #73, he seems to be injecting the event bus into the presenter > (I'm not used to MVP but it seems pretty logical to me). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
