Event Listeners and direct manipulation of Event Propagation

My recent inroads into PHP development were with respect to Event Handling and Event Listening.

Through a Mediator it was possible to create a concise and elegant platform to raise extensibility to another level.

As in Javascript, every Event Listener gets at least one Event to be manipulated in its own scopes:

$eventHandler -> addListener(

    'success', new Listener( function( Event $event, View $view, $message ) {

        $view -> success = $message;
    })
);

$eventHandler -> addListener(

    'error', new Listener( function( Event $event, View $view, $message ) {

        $event -> stopPropagation();

        $view -> error = $message;
    })
);

These are two actual examples implemented as part of the default Listeners of a base class for development of Plugins

They are very simple because they only provide information to the Application where the Plugins will be used, thus avoiding dozens of nested IFs just to mount a simple View.

Well, as in JavaScript, manipulable Events from within Listeners may have their propagation interrupted. And such a feature was also implemented so that the above Listeners were used as follows:

$application = new Application; # Fake
$view = new View; # Fake

$plugin = new Plugin( $application );

$plugin -> getEventHandler() -> handle( 'error', $view, 'message' );
$plugin -> getEventHandler() -> handle( 'warning', $view, 'message' );

Only the error listener would run. because the triggering process would be aborted if the Event had had its propagation interrupted.

Well, it occurred to me that during the rewrite of the Plugins, both to use the Plugins (which used to be an interface) as well as the Event Listeners , I had an epiphany that deep).

In the recent conversation in chat with @Omni I had confirmation that, in a hypothetical scenario, with a 1: N relationship between two subjects, where each Plugin would be one of the many relatable (N), in case the Plugin had its main task executed successfully, the Controller that executed the Plugin is who should change a fag in the database that characterizes that such step, of such Plugin, has been completed.

But what if, even though the Plugin was successfully executed, this flag update failed for some reason?

Like a successful Listener , a warning Listener might be triggered in sequence, but if for some reason propagation of the Event had been prevented in the successful Listener , the sequential Listener would be ignored.

And that's where my epiphany comes in:

  

It would be minimally plausible to operate manually, in global scope, the Event now manipulated in the local scope of a Listener so that when a next one was fired it would not be restricted by the interrupted propagation in the Listener previous?

My idea, currently implemented and fully functional, was something like this, though it was very abstracted and abstracted (but logically equivalent):

class Controller {

    private $application;
    private $view;

    // ...

    public function action() {

        $plugin = new Plugin( $this -> application );

        try {

            // Executes pre-execution routines

            $plugin -> onBeforeRun();

            // Main routine

            $plugin -> run();

            /*
             * Executes post-execution routines
             * Here is where the success Listener is
             * triggered and the Event Propagation stopped
             */
            $plugin -> onAfterRun();

            // Updates Plugin status

            try {

                // ...

                $repository -> update();

            } catch( SomeTableException $e ) {

                // Manuall restarting the Event Propagation

                $plugin -> getEventHandler() -> getEvent() -> startPropagation();

                $plugin -> getEventHandler() -> handle(

                    'warning', $this -> view, $e -> getMessage()
                );
            }

        } catch( SomePLuginException $e ) {

            // Plugin execution error. Handled differently
        }

        // ...
    }
}

That is, assuming that the Plugin was successfully executed but for some reason, perfectly fake for debugging, the repository entity could not be updated, another Listener would run only to warn that almost all went well, but for that, the propagation of the Event interrupted by the previous Listener should be reversed.

But, so far, I have not found any respect, not even in JavaScript to know if there would be such a possibility and / or if the venture would make sense.