Open boesing opened 1 year ago
+1 for this. Does it have to be delegator factories though (iirc these aren't the most performant)?
If we're firing the bootstrap event from the Application factory, would there be any need to register further factories via delegators (honestly no idea on that hence why I ask)?
We too have completely converted to using the config-aggregator
, but I'm sure that there are many that haven't, so I'd be hesitant to get rid of module manager completely and see that part of this as much more long term.
Does it have to be delegator factories though (iirc these aren't the most performant)?
Not sure what "not the most performant" actually means. Can you clarify? Delegator factories are only applied once. I'd say that having delegator factories over event listeners (as delegator factories are service-specific and in case the service is not used, the delegator has no TODO) will be the more performant way? Or do I miss something here?
If we're firing the bootstrap event from the Application factory, would there be any need to register further factories via delegators (honestly no idea on that hence why I ask)?
Can you elaborate? What do you mean with "firing bootstrap event from application factory"? This RFC targets the removal of those events, I do not really want to move these events to another location.
Delegators vs regular factories, I was told around v2 time that they should be avoided where possible for performance reasons. Maybe I misunderstood/misremembered or thats no longer the case. Still I typically avoid them so my suggestion was probably to just combine everything from the delegators into a single factory if thats possible? As I say, maybe thats not an issue anymore or never was.
Reading again its obvious the events are to be removed, not moved so not sure why I thought otherwise.
Maybe you have initializers
in mind? initializers do have direct performance impact as they are applied for any service. Delegators are service-specific and thus only trigger for those services which are requested.
Since most delegators are optional (especially those I am talking about), I don't see direct performance implication. So we either have:
Application#bootstrap
and Application#init
which is called once per request or we have dedicated delegators which are executed once per request. The amount of code is the same while the latter is at least optional and won't fire anything in case projects do not depend on those events. Thats at least the idea.
RFC
Goal
Removal of the method
Application#bootstrap
and the methodApplication#init
.This will automatically also supersede the
Bootstrap
MVC event. Whatever is being done in those event listeners should be moved to delegator factories. If something has to be configured in the application, theApplication
can be delegated, etc.This will also remove the ability to have (whyever) listeners being registered to the EventManager. These listeners can be registered via a delegator factory for the
EventManagerInterface
being injected toApplication::__construct
as well.Due to the latest changes being made to the skeleton, we suggest projects to provide
config/container.php
as we do inmezzio
. Thats awesome as that will actually move plenty of stuff to thatconfig/container.php
.I am aware of projects (even in our company) which are already migrating a away from
modulemanager
toconfig-aggregator
and thus, no modules are registered anymore since they provideConfigProvider
instead (and due to thelaminas-config-aggregator-modulemanager
, we are also providing full support to modules being provided asConfigProvider
).So by having a full container up and running via
config/container.php
(which for laminas-mvc-skeleton currently callsApplication#init($config)->getServiceManager()
), theApplication
is already fetched via$container->get(Application::class)
and thus, all the magic bootstrap/whatever logic can be added as delegator factories.If a project hardly depends on that bootstrapping logic, we can provide a
DelegatorFactory
which can be registered to the$container->get(Application::class)
which then triggers the event. I am open for ideas here.Background
Due to the huge amount of possibilities to configure the MVC application, etc. there is almost no way to catch all scenarios in
laminas-cli
. Thats all because too much logic is executed inpublic/index.php
instead of having the container configure that stuff.Considerations
Users might want to migrate their
MvcEvent#BOOTSTRAP_EVENT
to delegator factories ofApplication
. We do have to migrate our stuff to delegator factories (which is now being done in bothinit
andbootstrap
method). We do have to provide a proper factory for theApplication
due to the lack ofApplication#init
factory method).Proposal(s)
Application
factory to be registered to the containerApplication
fromcontainer
(already prepared https://github.com/laminas/laminas-mvc-skeleton/commit/1a242e41135d49f159a5d45cb5eec8c9639c1682)init
andbootstrap
to delegator factoriesAppendix
Ref: https://github.com/laminas/laminas-cli/issues/106 Ref: https://github.com/laminas/laminas-cli/issues/92 Ref. https://github.com/laminas/laminas-cli/issues/85