The EventBus and spring integration are already in existence. For parent-tree items, I put in the tree events but that's not a focus as I really only cared about consistent definitions of triggers, styles and templates which does not require a full event capability.
I used AOP to make the API consistent across all components everywhere and consistent in BXML specification. You don't have to do it that way as point out and as has been discussed on the list. -----Original Message----- From: Michael Allman [mailto:[email protected]] Sent: Monday, July 26, 2010 7:04 PM To: [email protected] Subject: RE: Backwards compatibility for WTKXSerializer I've already built something that works well for me. Essentially, it consists of events, event listeners, and event dispatchers. Component event dispatchers are tied in one-to-one correspondence with components through a component attribute. The component dispatcher does bubbling. There's a factory for turning Java methods into event listeners, because nobody likes defining anonymous classes. That's pretty much it. The event bus you describe with routing rules and whatnot sounds more complicated than what I need. Thanks for the tip, though. What's your name? Michael On Mon, 26 Jul 2010, aappddeevv wrote: > Message bus for inter-object communication versus parent-tree messaging > conceptually is the same, however, parent-tree messaging can be simplified > somewhat and built to be more optimized then a general-purpose message-bus > approach. There is general message bus, like spring integration, message > brokering like EventBus/e4 and then parent-tree bubbling like wpf. In terms > of routing strategy, parent-tree is pretty straight forward. Routing based > on strings/ids/header like EventBus can be managed well and adopting general > purpose mechanisms like spring integration is much more challenging. > > You can implement a bubbling router using attached properties, however, for > robustness, something more like WPF's style is a bit better and I switched > to AOP for a couple of reasons when I implemented events. You can create the > synthetic events by attaching listeners to all of the listeners in a > component (and other objects) and translate that into event message types. > One balance between the listener style in pivot and data-driven events is > that you have to flatten the listeners into event types...not hard at all. > When I built pivot-aspects, I flattened all the listeners into two common > APIs for PCL and events in order to go data driven and do event processing. > Doing this was the only way to be uniform throughout although there are > probably 2-3 ways to do it. Pivot already bubbles some events such as keys > and mousing which covers a lot of what people are usually after. > > I found that MessageBus does not solve enough of a problem to warrant its > use for many scenarios. It works fine for simple messaging though which is > what it was designed to do. EventBus has richer support for inter-object > communication and works fine and is easy to start using. I did not find > bubbling of a general event to be critical yet but flattening was important > for triggering. > > If you are looking for bubbling, I suggest you look at AOP to implement it > cleanly although build complexity increases. It would also allow to > implement handlers consistently without API requirements. I implemented > handlers for Execute/CanExecute and a pluggable handler framework so you can > have your own handler protocol but tastes vary. Because mouse/keys are > already handled okay, the need for robust bubbling was decreased as > supporting triggers required less infrastructure. In some cases where a > bubbling event could be helpful, walking the parent-child tree is a > quick-easy alternative to full event support. > > Here's some starting code for "tree events" > > > > /** > * A class for tree events to inherit from. Essentially, TreeEvent is the > "type" of event and this class is an instance of a TreeEvent. > Subclasses should extend for their event types. > * > */ > public class TreeEventInstance { > > public TreeEvent event; > /** > * The logical element that raised the event. > */ > public Component source; > /** > * The visual that raised the event. > */ > private Component originalSource; > /** > * The last sender of this event. > */ > private Object sender; > private boolean handled = false; > private Map<String, Object> attributes = new HashMap<String, Object>(); > .... > > > /** > * An event occurring in the tree. There are no > * interface or method requirements on the handlers for > * receiving these events. A tree event is > * really a message that has a potentially > * predefined notion of the direction to route. Instead of the class > * of the object indicating a payload type, essentially the id > * indicates a payload type in the message. > * > */ > public class TreeEvent { > > /** > * The routing strategy. This helps indicate > * how it should be routed when the context of routing up or down > * is well-defined. > * > */ > public enum Routing { > /** > * Event goes up the tree. > */ > UP, > /** > * Event goes down the tree. > */ > DOWN, > /** > * Event is only raised on the element and does not route up or down. > */ > DIRECT > }; > public String id; > public Class<?> ownerType; > public Routing routing; > ... > > > -----Original Message----- > From: Michael Allman [mailto:[email protected]] > Sent: Monday, July 26, 2010 12:29 AM > To: [email protected] > Subject: Re: Backwards compatibility for WTKXSerializer > > On Mon, 19 Jul 2010, Greg Brown wrote: > >>>> What other aspects of MXML would you like to see added to BXML? >>> >>> Simple support for listening for custom bubbling events. >> >> As I mentioned in a previous email, I think a pub/sub API is probably >> better suited to the use case you describe. > > I guess you're referring to MessageBus in trunk. If not, let me know. > > Anyway, I think using MessageBus for event bubbling is---to use an old > cliche---like hammering a square peg into a round hole. For one thing, it > uses classes for event/message keys. I want to select on a message > name---a string. For another, MessageBus is global. A subscriber does > not know the source of the message without examining the message. I would > like to be able to subscribe for messages from an event dispatcher of my > choosing. Thus, I can have multiple event dispatchers dispatch the same > type of event and take a different action depending on which event > dispatcher dispatched the event. Finally, there's bubbling itself. > MessageBus does not provide support for bubbling, probably because it > doesn't know anything about the component hierarchy. I would like to be > able to "consume" events in such a way that ancestor listeners do not > receive them. > >>> Also, being able to bind to arbitrary properties on suitably annotated >>> objects would be very helpful >> >> This is already supported. The BXML annotation supports an "id" property >> you can use to bind to any named object in the BXML file. It just >> defaults to the name of the member variable. > > I think we're referring to two different kinds of binding. I'm referring > to the event-driven kind. Are you? > > Cheers, > > Michael >
