> Pardon me, but it looks to me that what you are describing as a Flex
> advantage, indeed it's a Flex limitation. First, it's not true that only
> Swing objects can participate to events: any object can implement any
> listener.
Yes but realize that you are rolling your own event listener system
there. You don't get any advantages of event bubbling, or can take
advantage of the component heirarchy to route events up or down the
tree. Swing choose to force everyone who wanted to create their own
events to write the addListener/removeListener/fireEvent methods
themselves. EventListenerList helps, but you still have to delegate
those listeners to it. And you have to route the messages yourself if
you want that. Because Swing choose to make it soo difficult to build
a real event system.
When I say Swing's event system is closed I mean that components can't
really plugin to dispatchEvent() in any meaningful way. In fact
internally it's a big old switch statement in Component. Yuck!
There's no way to add your own register events or listener for events
dispatched from dispatchEvent() efficiently. Reason for that is
because the gutted it in 1.1 and it's been abandoned.
PropertyChangeListener does allow you to use it in a generic fashion,
but I'd say it's far more cumbersome than DynamicEvent in Flex. Not
really the samething.
> This has been discussed the past week about Oberon. I have yet to
> understand in a concrete case why this approach is useful - an external
> controller that is able to listen to an inner button event sounds very
> much as peeking its nose into some implementation details (why should it
> know that there's such button), that is bad separation of concerns.
> Certainly this could make implementation of UIs faster, but with many
> doubts about their design. It sounds as the old "faster vs better" -
> which doesn't mean that Flex is bad, but lead me to think that Flex is
> good for stuff that needs to be made quick and dirty, and with no long
> life. Can we elaborate on a concrete use case?
Yes because event bubbling is probably my favorite thing about the
Flex toolkit. But, it's not like this is new bubbling happens in HTML
DOM model for Javascript events as well. I think the reason it's not
as useful there is simply the lack of separating the page into
discrete components. And that you really can't create your own events
very easily. Sorry for the tangent.
The use case is quite the opposite of what you think it's for.
Bubbling is NOT so a Controller can listen for button click inside
some embedded component. That would coupling the controller too much
the UI as you stated. Instead it enables decoupling between the UI
and controller with what I'll call Application Level Events. So when
the developer is creating a component he puts a button in the UI, and
he registers a click listener on that. Now, clicking the button
usually involves several actions to occur some of them pertaining to
the UI, and somethings pertaining to the actual action to take. Those
UI actions depend on how the UI is put together and the choices the
developer made when creating the UI. Those choices should remain the
UI's responsibility. So the listener the person registers needs to
handle the UI portions, but delegate the actions to the Controller.
Bubbling allows you to separate those two things by registering a
listener that will do the UI portion it needs to do, then dispatch
another Higher Level Event (aka the Application Level Event) to the
outside to take care of the heavy lifting. So it might look like
this:
public doClick( event : MouseEvent ) : void {
// do some updates to the UI because the user clicked a button
podcast : Podcast = table.selectedItem;
showSpinningWheel( podcast );
// maybe grab the selection from the table in the UI.
event : Event = new ApplicationEvent( 'podcast.refresh' );
event.podcast = podcast;
dispatch( event );
}
In the controller I can do something as easy as:
podcastView : PodcastView = new PodcastView();
view.addListener( 'podcast.refresh', refresh );
In flex it's even easier since you can do this in MXML, but I'm trying
to keep this somewhat similar to what we all understand. I'd be
interested in how you can do this in JavaFX when laying out the UI.
Notice though how the controller doesn't care where the event is
coming from within the PodcastView, but he just knows that event comes
out of it. He doesn't get involved of what is in the UI. And that
bubbling takes care of routing the event to the top for us without us
having to write special routing code. Imagine having to do that in
Swing.
This event I'm dispatching allows you to divide the UI actions from
the Controller's actions. So the outside controller is blissfully
unaware that I have a table, a button, or that the spinner is moving.
This ApplicationEvent is a user defined event. The toolkit allows me
to dispatch the event and that event will bubble up the hierarchy so
the Controller can receive that event without needing to dig around
inside the UI and register a listener at the exact place where the
event will be dispatched from. This decouples the details of the UI
from the portion that will perform the action.
Therefore, my Controller is separated from my UI cleanly. And, the UI
doesn't depend on the Controller to route events to the model layer.
It just dispatches an event, and the controller receives it. That
listener I showed could be embedded in Panel after panel after Panel,
but with bubbling it will rise to the top and the controller can
effortlessly receive events from lower level UI items.
I hope this helps clarify why bubbling is so useful. If not I'll be
happy to describe it more.
Charlie
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" 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/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
