As Thomas says, only introduce an event when needed. Also, remember that there is no point to an event if nothing else is interested.
If you only have one list of cars, then a CarAdded event is not needed since the list can deal with the server response directly. The same is true of the other events (and maybe also StartCar, StartNewCar, CarStarted, StopCar, StopNewCar, CarStopped if I had any idea what they were for). So in the scenario you explained, if the dialog is a popup, then since you haven't mentioned any other page, there is, as yet, no need for any events at all. Now if you had a page for adding cars and another page listing cars (on, say, another tab) then there's a need for an event. In an optimistic UI, when the Add page submits the 'add' you fire a CarAdded event and the list (and anything else subscribed to this event) will respond accordingly. If, subsequently, the server reports that the add failed, you'll need an undo event to. More work, but it gives a more responsive feel for the user. In a pessimistic (traditional) UI, when the Add page, when the server reports that the add was successful, you fire a CarAdded event so that the list can respond. Easier, but the user sees a lag between pressing the button and seeing the update, and if they switch quickly to the list, their new entry might take a few moments to turn up. If, somewhere in my app, I do something, I don't just tell the world in the desperate and pathetic hope that maybe somewhere, sometime, something or someone might take an interest in the boring, mundane minutiae of what I'm doing. An event bus is not the programming equivalent of Twitter :-) My pages are more of the busy executive, working efficiently on their own initiative as far as possible, and sending out memos on a strictly 'need to know' basis as well as responding to incoming ones. Or something like that. Ian http://examples.roughian.com 2009/11/16 Thomas Broyer <t.bro...@gmail.com> > > > On Nov 15, 3:19 am, "slind...@gmail.com" <slind...@gmail.com> wrote: > > I am attempting to implement the EventBus pattern and I find myself > > creating a LOT of Events (extending GwtEvent). I'll try to illustrate > > what I mean with my Car object. I have a list of cars and a button > > called "Add Car". This button has a ClickHandler attached which will > > fire a AddCarEvent. > > > > This AddCarEvent in turn triggers the display of a dialog where the > > user can enter details of the car like make, model, etc. This dialog > > naturally has a button called "Save" with another ClickHandler > > attached. This ClickHandler fires a new event slightly different from > > AddCarEvent since we now have some details of the car, so I'm calling > > this event AddNewCarEvent. The event bus has a listener that triggers > > when this event is fired and makes an asynchronous call to the server > > with the details of the new car. The server returns the newly created > > Car object (or id of it), and a new CarAddedEvent is created (this > > event in turn might trigger a LoadCarsEvent to refresh the list of > > cars). > > > > I figured I can save myself from the AddNewCarEvent by adding > > properties like "model", "make" etc to the AddCarEvent object. If they > > are set I'll make the async call, if not I'll display the dialog. This > > saves one Event class but I still think there must be some better way. > > This is just one object, and one simple action; but it quickly gets > > out of hand when adding more objects and actions (ie. a Car could have > > StartCar, StartNewCar, CarStarted, StopCar, StopNewCar, CarStopped > > events and so on..). > > > > I hope this doesn't sound too crazy, and I hope someone has some ideas > > to improve and perhaps simplify this, unless this actually is a > > "natural" side effect of this pattern? > > In our app, the dialog would do the RPC call (and handle errors – > though not failures, which go to a global handler–) and fire an event > on success. Now, you also have to decide if you really need the > granularity of a CarAddedEvent compared to a > CarAddedUpdatedOrDeletedEvent of some sort. > > My rule of thumb: do not over-engineer; only introduce an event when > you *need* it, not when you "think you might need it in the future, > perhaps, depending on how you code the rest of your app". > For instance, if you know your "user preferences dialog" will only be > trigger by a single button, don't do an event for it, just call your > dialog from the button's click handler. Later on, if you happen to > have to call points for the user preferences, then refactor your code > to add an event. > > -- > > 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-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=. > > > -- 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-tool...@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=.
