In my use case I'd benefit of being able to catch all events fired by components throughout the system, and act on them. What do you think?
<?php
use Phalcon\Events\Event;
use Phalcon\Events\Manager as EventsManager;
$eventsManager = new EventsManager();
$eventsManager->attach("*", function (Event $event, $data = null) { // do work });
Well im not sure, there is really A LOT of events in phalcon, not sure if it's a good idea.
There is an ability to use Manager::attach('group', $callable) to listen all group's events eg group:foo, group:bar, etc. Also you can get a list of all Phalcon event using grep from the project root as follows:
egrep -ir 'fire(Event)?\("([a-z]+(:[a-z]+)?)"(,\S?.+)?\)' phalcon | \
awk -F'fire' '{print $2, $1}' |\
sed -e 's/Event//g' | \
awk -F'zep:\\s' '{print $1}' | \
sed -e 's/("//g' | \
sed -e 's/"\(.\+\)\?\();\|{\)//g' | \
sort | \
awk '{print $1, $2"zep"}' | \
column -t
acl:afterCheckAccess phalcon/acl/adapter/memory.zep
acl:beforeCheckAccess phalcon/acl/adapter/memory.zep
afterCreate phalcon/mvc/model.zep
afterDelete phalcon/mvc/collection.zep
afterDelete phalcon/mvc/model.zep
afterFetch phalcon/mvc/model.zep
afterFetch phalcon/mvc/model.zep
afterSave phalcon/mvc/collection.zep
afterSave phalcon/mvc/model.zep
afterUpdate phalcon/mvc/model.zep
application:afterHandleRequest phalcon/mvc/application.zep
application:afterStartModule phalcon/mvc/application.zep
application:beforeHandleRequest phalcon/mvc/application.zep
application:beforeSendResponse phalcon/mvc/application.zep
application:beforeStartModule phalcon/mvc/application.zep
application:boot phalcon/mvc/application.zep
application:viewRender phalcon/mvc/application.zep
collectionManager:afterInitialize phalcon/mvc/collection/manager.zep
console:afterHandleTask phalcon/cli/console.zep
console:afterStartModule phalcon/cli/console.zep
console:beforeHandleTask phalcon/cli/console.zep
console:beforeStartModule phalcon/cli/console.zep
console:boot phalcon/cli/console.zep
db:afterQuery phalcon/db/adapter/pdo.zep
db:afterQuery phalcon/db/adapter/pdo.zep
db:beforeQuery phalcon/db/adapter/pdo.zep
db:beforeQuery phalcon/db/adapter/pdo.zep
db:beginTransaction phalcon/db/adapter/pdo.zep
db:commitTransaction phalcon/db/adapter/pdo.zep
db:createSavepoint phalcon/db/adapter/pdo.zep
db phalcon/events/manager.zep
db:releaseSavepoint phalcon/db/adapter/pdo.zep
db:rollbackSavepoint phalcon/db/adapter/pdo.zep
db:rollbackTransaction phalcon/db/adapter/pdo.zep
dispatch:afterBinding phalcon/dispatcher.zep
dispatch:afterDispatchLoop phalcon/dispatcher.zep
dispatch:afterDispatch phalcon/dispatcher.zep
dispatch:afterExecuteRoute phalcon/dispatcher.zep
dispatch:afterInitialize phalcon/dispatcher.zep
dispatch:beforeDispatchLoop phalcon/dispatcher.zep
dispatch:beforeDispatch phalcon/dispatcher.zep
dispatch:beforeException phalcon/cli/dispatcher.zep
dispatch:beforeException phalcon/mvc/dispatcher.zep
dispatch:beforeExecuteRoute phalcon/dispatcher.zep
dispatch:beforeForward phalcon/mvc/dispatcher.zep
dispatch:beforeNotFoundAction phalcon/dispatcher.zep
loader:afterCheckClass phalcon/loader.zep
loader:beforeCheckClass phalcon/loader.zep
loader:beforeCheckPath phalcon/loader.zep
loader:beforeCheckPath phalcon/loader.zep
loader:beforeCheckPath phalcon/loader.zep
loader:pathFound phalcon/loader.zep
loader:pathFound phalcon/loader.zep
loader:pathFound phalcon/loader.zep
loader:pathFound phalcon/loader.zep
micro:afterBinding phalcon/mvc/micro.zep
micro:afterExecuteRoute phalcon/mvc/micro.zep
micro:afterHandleRoute phalcon/mvc/micro.zep
micro:beforeException phalcon/mvc/micro.zep
micro:beforeExecuteRoute phalcon/mvc/micro.zep
micro:beforeHandleRoute phalcon/mvc/micro.zep
micro:beforeNotFound phalcon/mvc/micro.zep
modelsManager:afterInitialize phalcon/mvc/model/manager.zep
notDeleted phalcon/mvc/model.zep
notSaved phalcon/mvc/model.zep
notSave phalcon/mvc/collection.zep
onValidationFails phalcon/mvc/collection.zep
onValidationFails phalcon/mvc/model.zep
onValidationFails phalcon/mvc/model.zep
onValidationFails phalcon/mvc/model.zep
onValidationFails phalcon/mvc/model.zep
prepareSave phalcon/mvc/model.zep
router:afterCheckRoutes phalcon/mvc/router.zep
router:beforeCheckRoute phalcon/mvc/router.zep
router:beforeCheckRoutes phalcon/mvc/router.zep
router:beforeMount phalcon/mvc/router.zep
router:matchedRoute phalcon/mvc/router.zep
router:notMatchedRoute phalcon/mvc/router.zep
view:afterRender phalcon/mvc/view.zep
view:afterRender phalcon/mvc/view/simple.zep
view:afterRenderView phalcon/mvc/view.zep
view:afterRenderView phalcon/mvc/view/simple.zep
view:beforeRender phalcon/mvc/view.zep
view:beforeRender phalcon/mvc/view/simple.zep
view:beforeRenderView phalcon/mvc/view.zep
view:beforeRenderView phalcon/mvc/view/simple.zep
view:notFoundView phalcon/mvc/view.zep
@sergeyklay I鈥檓 aware of group events and I saw list of all phalcon events in docs, but consider 3rd party components - this approach still limits devs to only known events.
i.e. you are building plugin system and you want to let developers hook/lazy load plugins on specific event (which may be fired by other plugin and therefore is uknown to plugin system developer) and that way avoid unneccessary file lookups and inclusions. That plugin system would need to catch all events and then decide if there are plugins associated with it. This is is just from top of my head, I believe there are many more legit uses of that feature which I also believe is not hard to implement. I can even write a pull for it.
I think the decision whether to support this feature or not should be based on whether there are use cases for it or not, and not on number of events...
Tons of phalcons features can negatively impact performance if not used properly and carefuly, which didn鈥檛 stop us from including them.
+1, I can see this being useful for logging and/or debugging purposes.
Then once you know what events are coming in, it would be easy to setup a switch without having to browse through loads of documentation, or pull apart the cphalcon repo, to figure out what events are firing.
Having the entire event list automatically generated and stuff into the docs as an appendix of some sort would be very nice. Perhaps a nice middle ground between introducing new code into cphalcon and giving the developers some hints as to what they can listen for.
Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues
Most helpful comment
There is an ability to use
Manager::attach('group', $callable)to listen all group's events eggroup:foo,group:bar, etc. Also you can get a list of all Phalcon event usinggrepfrom the project root as follows: