>>>> 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.
OK. >>> 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? I am talking about mapping BXML variables to class members. I guess I don't understand what you mean by event-driven binding.
