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