We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Attaching events - Component names?

I'm trying to get a better understanding of events. One thing I'm unsure of is where we can get the component names of what we want to attach to. For instance:

$di->set('dispatcher', function () use $di {
    $dispatcher = new Dispatcher();
    $dispatcher->setDefaultNamespace('Vokuro\Controllers');
    return $dispatcher;
});

Even though the service is called "dispatcher" if i want to attach a listener to this component, I need to use:

$eventsManager = $di->getShared('eventsManager');
$listener = new ListenerClass($di);
$eventsManager->attach('dispatch', $listener);

So how would we know to use "dispatch" for the dispatcher, or "db" for the database component? Is there a list somewhere I'm not seeing of all the event aware components we can set listeners too?

--Mark



98.9k

Those were names arbitrary chosen, I'm afraid that there is no list mentioning all these names. Every chapter in the documentation mention how events are dispatched and what prefix is used. It would be great to build one list with all the prefixes.

In the documentation is good, in the code would be even better. As I'm not a C programmer, I have one question @Phalcon. Is it possible, as part of the compilation process, to scan the .c files for class properties? If that's possible without lots of hacks, I was thinking of the following:

In each class that has events, there are two new protected properties: eventType - The string name of the event prefix used in this class validEvents - Array of valid events for that can are triggered in that class

At compilation, two protected properties are generated in Phalcon\Events\Manager: eventTypes - array of class eventType => className validEvents - array of [class eventType => array of class events, ...]

Getters and setters - getEventTypes(), setEventType() - push onto existing array getValidEvents(eventType), setValidEvents(eventType, array events) - push onto existing array

Sound good? if so, I'll make an NFR in GitHub



98.9k

We have more options to do that:

1) Check the Zephir sources out, they can be easily read and they implement the same events and prefixes as 1.2/1.3: https://github.com/phalcon/cphalcon/tree/2.0.0/phalcon

2) Introduce the methods you said, however, I don't know if we need this level of customization, since this would add more overhead, because we need to get the right prefix from the property first and then dispatch the event.

True, that would introduce an extra call. After sleeping on it, I can't think of a situation where, in production code, you would want to access a list like this. You should already know what event you want to listen to. It's most helpful in developing I guess, and we have the docs for that.

[EDIT] @boston has a more complete list



5.0k
Accepted
answer

Also recently made ​​a list of events, only need to select examples and startup options:

dispatch:
    beforeDispatchLoop
    beforeDispatch
    beforeNotFoundAction
    beforeExecuteRoute
    afterInitialize
    afterExecuteRoute
    afterDispatch
    afterDispatchLoop
    beforeException

cli:
    dispatch:beforeException

loader:
    beforeCheckClass
    pathFound
    beforeCheckPath
    afterCheckClass

acl:
    beforeCheckAccess
    afterCheckAccess

console:
    beforeStartModule
    afterStartModule
    beforeHandleTask
    afterHandleTask

db:
    beforeQuery
    afterQuery
    beginTransaction
    createSavepoint
    rollbackTransaction
    rollbackSavepoint
    commitTransaction
    releaseSavepoint

application:
    boot
    beforeStartModule
    afterStartModule
    beforeHandleRequest
    afterHandleRequest
    viewRender
    beforeSendResponse

collection:
    beforeValidation
    beforeValidationOnCreate
    beforeValidationOnUpdate
    validation
    onValidationFails
    afterValidationOnCreate
    afterValidationOnUpdate
    afterValidation
    beforeSave
    beforeUpdate
    beforeCreate
    afterUpdate
    afterCreate
    afterSave
    notSave
    notDeleted
    notSaved

micro:
    beforeHandleRoute
    beforeExecuteRoute
    afterExecuteRoute
    beforeNotFound
    afterHandleRoute

model:
    notDeleted
    notSaved
    onValidationFails
    beforeValidation
    beforeValidationOnCreate
    beforeValidationOnUpdate
    afterValidationOnCreate
    afterValidationOnUpdate
    afterValidation
    beforeSave
    beforeUpdate
    beforeCreate
    afterUpdate
    afterCreate
    afterSave
    notSave
    beforeDelete
    afterDelete

view:
    beforeRenderView
    afterRenderView
    notFoundView
    beforeRender
    afterRender

collectionManager:
    afterInitialize

modelsManager:
    afterInitialize

volt:
    compileFunction
    compileFilter
    resolveExpression
    compileStatement