Hi Benju, The use of the HasClickHandlers interface (and other Handler interfaces) is actually just a piece of event-driven architecture that GWT subscribes to in the 1.6 event handler architecture. Basically, anything that implements the HasClickHandlers interface must provide an implementation for the methods that manage ClickHandlers added to it.
You can apply this principle more generally to your own components. For example, a component that sends EmergencyEvacEvents or wraps a widget that does so might also implement a HasEmergencyEvacHandlers. Whenever the EmergencyEvacEvent occurs, components implementing HasEmergencyEvacHandlers will be responsible for notifying each of the handlers to handle the emergency event. The following article also explains the same concept through a more complete example (though the article is outdated as it pertains to GWT 1.4). "Developing Web 2.0 Apps with the Google Web Toolkit" (see section Wiring Event Listeners): http://www.linux-mag.com/id/5444 Regarding resources that explain how the MVP pattern relates to GWT, I think the following article on testing methodologies using GWT will help. "Testing Methodologies Using Google Web Toolkit": http://code.google.com/webtoolkit/articles/testing_methodologies_using_gwt.html Although the article focuses on testing methodologies, the MVP pattern is explained in code as it helps make it easy to isolate components that we want to test and mock out any other components that it might interact with. Hope that helps, -Sumit Chandel On Fri, Jun 12, 2009 at 10:19 AM, Benju <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
