active events
Thinking about events yesterday made me wonder why there is actually a very specialised method filterResponse() for plugnis. One of the reasons was that I thought it would be nice for regular code to be able to modify the response, too.
One example of why that could be useful is CSS. In contrast to importing JavaScript, CSS needs to be imported/references in the <head> section of a HTML page. That means if the code that generates the HTML needs some special CSS this needs to be handled way in advance of where the code is actually executed.
One idea is to have some sort of resource manager that is able to access the final HTML and inject all the CSS [either explicitely or by linking .css file(s)]. That way the fact that new CSS rules are required would not need to be known in advance.
One obvious use case would be the new widget class, of course!
Looking at the code I remembered the real reason why this is so special: the HTML contents is passed into the method as parameter and the modified contets returned used as parameter for the next plugin, and so on.
Currently, events do not return values. The only parameter is a hash map that may contain any type of data.
So, to cut to the point, I changed the fireEvent() method to optionally handle return codes. The default behaviour is compatible to the current use, however it is possible for event subscriber to return a changed array.
Strictly speaking this is not really necessary as it is possible to modify the parameter array due to the reference handling in PHP5. Still, should special events require a contract where the parameter is not an array things should be ok.
So, as o f the next release [0.9.5] content filtering will be available to every piece of code that whishes to do so.
