4

Following up on this question of mine, where I wanted to know the general principles of implementing an event dispatching system that allows for events to bubble (and capturing I've come to learn); does such an implementation make any sense for non-GUI related objects?

I'm asking, because I want to try and build a general purpose event dispatching framework in PHP (be it just for practice or for real use), but can't figure out whether event bubbling (or capturing) is in anyway useful in such an environment (not talking about PHP-GTK or similar environments here).

Improve this question

2 Answers 2

Reset to default
5

Of course it does make sense. Just because you can't see something visually does not mean it can't use event bubbling, much less events in general.

An illustrating example:

Imagine you have some sort of tree model, for example an organigram of a company and you want to notify the higher ups when a node is inserted (new employee) or something has changed. You could then, for example, raise the event "Developer Jane just married, her surname changed to Smith". Some of the higher ups (such as her deparment lead) might be interested in such an event and send a greeting card, raise her salary or simply congratulate her. Just bubble it up, so the higher ups needn't subscribe to the surname change event of every person in the company, but get it anyway and can handle it, if they want to.

The logic would be much more complicated when they had to subscribe events from each individual. Whenever an individual was added, you'd have to traverse the tree for people interested in the new individual and subscribe to any events of interest explicitly. From a programmer's perspective, this is much more complicated then just receiving the event and then deciding whether you're interested in it or not. It'd lead to a pretty complex net of interconnections that is more difficult to manage and maintain. The first thing that comes to my mind are possible serialization troubles.

Now I am sure there're better examples out there, this was just the best one I could come up with in 30 seconds. But as you're intending to build an event dispatching system, I'd like to point you to the event aggregator pattern, which is a nifty little multipurpose tool that such a framework should not miss, best implemented like Microsoft does it in my opinion.

Improve this answer
0

If you are building your own system you would be wise to study how the tk toolkit handles bindings. It associates a list of tags (or bindtags) for eAch widget. When an event comes in on a widget, the library gets the list of tags and looks for and applies each binding in order.

By default tne order is most specific (ie: the widget itself) to least specific (ie: the topmost window). The beauty of the system is, you can define whatever order you want. 98% of the time the default order is what you want, but sometimes you need something different.

The other feature of this system is that each binding can choose to have the event bubble or not. If a handler wants complete control it can handle the event then break the chain. Or, it can do what it needs to do then let other handlers have their turn.

I've never worked with a more powerful, flexible and simple method of handling events.

Oh, and there is no limitation that tags have to represent visible objects, or even objects at all. You can have tags that represent abstractions (for example, by default every widget includes the tag "all", which means you can bind to "all" and it will fire no matter where the event originally occurs.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.