Plugin introspectable event interface

Asked by Javier Collado on 2009-05-28


I've just written a small script that parses a test suite file and plots the test cases in graph using the dependency information so it's clearly displayed which test case will be skipped in case of some other one fails.

I though it would be great to write a similar script that extracts checkbox plugin event interface (i.e. events to which a subscribe is subscribed via call_on method and events that might be fired using the fire reactor method) and displays a graph that shows the relationships between plugins. Of course, this won't explain when a plugin a fires an event and what do the callbacks methods upon even reception. However, it could be used to clarify the relationships established between callbacks. Unfortunately, this isn't currently possible because that information isn't externally available.

To be able to solve that problem, I thought about this approach:
- Store the list of events that might be received/fired by this plugin in a class variables (maybe this could be added through class decorators so that this information isn't only available programmatically, but also easy to find in code).
- Add a checks in code so that plugins cannot subscribe to or fire events that they have not declared as part of their interface

Please let me know what do you think about this idea. If it looks fine to you, then I might write some proof of concept code to see how it works.

Best regards,

Question information

English Edit question
Checkbox Edit question
No assignee Edit question
Solved by:
Javier Collado
Last query:
Last reply:
Launchpad Janitor (janitor) said : #1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Marc Tardif (cr3) said : #2

Sorry I didn't notice this question earlier. It would indeed be useful to provide a mechanism to introspect events and/or handlers. I have already pushed some tentative code to generate a dot graph from events being dispatched thoughout the framework:


The problem is that there still isn't a clear interface to introspect events. In the graph plugin of the above branch, I have introduced the concept of a HandlerInfo in order to wrap relevant information about handlers into a convenient container. This concept feels like the right direction but that still needs to be proven.


The HandlerInfo works fine and no change is needed to the rest of plugins so I would say is a good solution to experiment with checkbox. Thanks.

Best regards,