I don't see any reason why the TabPresenter can't listen for events on the main event bus.
People talk about not wanting to "crowd the event bus". I'm not sure what they mean by this, though I can think of three things: 1. Volume of events 2. Diversity of event types 3. Number of registered event handlers For the first one, you have to remember that you're running in Javascript in a web browser. When you post an event to the event bus, it gets processed and all listeners are notified immediately, in series. The event bus isn't holding on to events until some processing thread wakes up to process them, so there's never a backlog of events to process. Incidentally, you also have to keep this in mind when choosing the order of events when you have multiple events to fire. When it comes to diversity of event types, handlers are registered for particular event types and are put into different buckets based on that type. When the event bus goes to choose the handlers, it knows the event type and can locate them quickly. Before moving to HandlerManager, I wrote my own event bus that was simply a HashMap of event type to Collection of handlers. Looking at the source for HandlerManager, that's exactly what it does as well. Assuming GWT's Javascript implementation of HashMap is reasonably efficient, having handlers for many different types of events shouldn't be a problem. As for the number of event handlers registered, that shouldn't actually get too out of control in practice. No matter how large the application is, the scope of what the event bus needs to handle at any one time is limited to what's displayed in the browser at one time. If a view is hidden, it shouldn't have any handlers registered (aside from maybe a place change handler). This is addressed during the Q & A of Ray Ryan's Google I/O talk (around 46:00 - 49:00) and Ray's answers are excellent. To reiterate one very important part of that (as I don't feel it's emphasized enough): you always have to be careful to unregister any handlers when they become irrelevant (such as when a view is dismissed or replaced with a different view). As long as you do that, the size of the application becomes largely irrelevant. There are two cases I can think of where having a separate event bus might be useful: 1. Prioritizing event delivery 2. Automatic clean-up of event handlers When using a single HandlerManager, you don't have much control over the order that event handlers are notified; it depends entirely on the order in which they were added and whether the HandlerManager instance is configured to fire handlers in "reverse" order. If you have a "local" event and you want to make sure that, for example, the related view gets first stab at it, you could create a local event bus that will automatically propagate the event to the global event bus where the less important handlers are registered. I think that these cases would be rare, and you can get the same effect by chaining two events/ handlers rather than two event busses. Finally, it would be nice if you could create a local HandlerManager that would clean up all of its handlers automatically when the view changes. I don't think that the current HandlerManager implementation does anything like this. It could probably be done, but would still require discipline to explicitly deconstruct HandlerManager instances when they're no longer needed. Plus, it could be confusing for the object owning the handler for it to be implicitly unregistered. -Brian On Jan 29, 5:05 am, Abdullah Shaikh <[email protected]> wrote: > Hi Thomas, > > I understand EventBus is for decoupling things .. but I guess there are > sometimes where you would want to use multiple (local) event bus. > > I don't know may be I am missing something .. let me explain you my case > > I have a DockPanel where I have added Widgets (panels) on West, Center & > East directions. > > The panel on the west side contains navigation links and when clicked the > content is displayed on the center panel. > > I was able to do the above navigation & displaying because the DockPanel was > the part of main presenter/view and I could easily access the DockPanel and > change the content of center panel. > > But there is a time when I have a TabPresenter (which has a Tabpanel) into > my center panel, and in the first panel of TabPanel there is a button which > should fetch some data from server and display it in the second panel of > TabPanel. > > Now if I do this using the app wide EventBus bus, I won't have access to the > TabPanel because it's inside of TabPresenter, in the app wide EventBus I > could only create TabPresenter and add it to center panel but cant access > TabPanel. > > or should I have getTabPanel in Dispay of TabPresenter and manipulate it in > app wide eventbus ? I don't think this should be done like this. > > a local EventBus which will be a part of TabPresenter will be good for this > case I guess. > > - Abdullah > > > > On Fri, Jan 29, 2010 at 3:00 PM, Thomas Broyer <[email protected]> wrote: > > > On Jan 29, 8:46 am, Mirco Dotta <[email protected]> wrote: > > > Hi, > > > > This is a question I've been asking myself several times, here is the use > > > case: > > > > I've got an action happening in a ChildPresenter, such as a > > > DeleteElementEvent. > > > The ParentPresenter would like to register to this type of events so that > > a > > > correct > > > reaction can be triggered. > > > > Now, a possible way to go is to pass the Event in the EventBus and having > > > the ParentPresenter > > > registering on the EventBus for such events. This is going to work, but I > > > really don't like this > > > solution as the Event is not application-wide and therefore should not be > > > polluting the event bus. > > > > I'd rather have a local event, but how can I achieve this? Should I > > create a > > > HandlerManager > > > it in the ParentPresenter... but then hwo can I pass it to the children > > (GIN > > > injection?!, but how?). > > > > I'm looking for a pattern, if anyone faced the problem and came up with a > > > solution, please share :) > > > The EventBus is there to help you decouple things. If you want to > > "couple" them, then it's OK to not use the EventBus (you've been > > warned about strong coupling and its implication on code maintability > > though) > > > You could follow the same pattern that is used in GWT widgets: > > - have a HandlerManager in ChildPresenter > > - ChildPresenter expose a addDeleteElementHandler method that adds > > the handler in the internal HandlerManager > > - the ParentPresenter registers its handler directly on the > > ChildPresenter > > - ChildPresenter fires the event at its internal HandlerManager > > rather than the EventBus > > > This is really strong coupling though. You've been warned... > > > Another solution would be to have several event buses. > > > But actually I don't really understand why it is a problem to fire the > > event at the EventBus if you already have one... > > > -- > > 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]<google-web-toolkit%2Bunsubs > > [email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- 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.
