Too much is happening (the events are crowding the bus)?

[slin...@gmail.com]

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?


Thanks and regards,
Stian

[Thomas Broyer]

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.

[Ian Bambury]

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.br...@gmail.com>

--

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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=.

[ArmanGal]

I use Operation enum inside the action that tells my presenter how to
handle the action. + I create number of constructors for this event to
support every operation, while the event it self has all needed
properties for all operations.

;)

[Matt Bishop]

Your simple, many-classes design is actually a Good Thing. Event
objects should really only do one specific step in the workflow of
your application. Lots of small, discrete and completely specific
action classes is far preferrable to a smaller set of classes that
contain if-then-else trees and switch statements.

Don't be afraid of lots of small classes, it is usually a good thing.
As Grady Booch once wrote, if your application code is too complicated
to understand, break things down further with more classes.

[Arthur Kalmenson]

I agree with Matt here. We also followed the same principle of having
many smaller events, meaning a Presenter will get only the event it
wants to listen to. Using an enum in the event could work too, but
again as Matt pointed out you'll end up having if-then-else trees,
which is hard to read, test and maintain. We are able to reuse some
events by making them generic.

It's going to be up to you, you can either go with a hybrid bus
architecture where classes reach into each other and listen to events
directly, or you can go for a full bus architecture where _everything_
that happens is an event. The latter has the advantage of being highly
decoupled, while the former has the advantage of having fewer event
classes and maybe easier to understand the flow because there is some
coupling.

--
Arthur Kalmenson

[mariyan nenchev]

Hi,
I am interested in this gwt architecture too. I did have a look at the video and a hello world application implemented with this architecture, and really i think that this is too much code to write. I also looked at the apache hupa project, that is using the same architecture. And they did a generic events for add,edit, delete, fetch, so you only will need to add new events for your custom cases, which is not so bad.
I as we speak for this, does any one else know other open source projects written with this architecture. I want to have a look at them, since a mail client (hupa) is not the best to learn from.

Regards.