On Nov 15, 3:19 am, "[email protected]" <[email protected]> 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 [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=.
