User tests: Successful: Unsuccessful:
This is concept of loading the plugins on demand.
The idea (not new) is to instantiate the plugin only when the event is triggered, thus reduce App initialisation and execution in general. This can be achieved for plugins that implements SubscriberInterface
.
The PR contains an examples based on: LanguageFilter, Debug and GuidedTours plugins.
It works as folowing:
PluginHelper::importPlugin()
reading the plugin event with getSubscribedEvents()
, and creates a clousore for each.
When the event is triggered the closure is looking for the plugin instance, and executes the event method.
Instead of use $app->bootPlugin() it introduce $app->getPluginContainer(), which allows to retrieve the plugin information without booting it in first place.
New options for plugin service:
plugin.information
Define the plugin class name, and implemented interfaces. This is important to be able to get the class name without booting whole plugin. (Should be probably some kind of configurable class, that can read this information from XML automaticaly, or set by developer. Need to discuss, please share your ideas)plugin.executeValidation
Validate if the plugin should be executed in current runtime. This solves long standing problem, when we have to run $app->isClinet('potato')
in many events. (Should probably also be some kind of configurable class. Need to discuss, please share your ideas)The PR uses a simple arrays for new options, however it is only for purpuse of demonstration. Some of these things need to be updated to to proper Class/Interface.
impact on existing plugins:
Zero, Null, Nulo, no backward compatibility break. All existing plugins will work as before.
The PR can be merged without testing.
Please select:
Please share your opinions ?
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries Front End Plugins |
Labels |
Added:
RFC
Feature
PR-5.2-dev
|
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-06-15 11:24:31 |
Closed_By | ⇒ | Fedik |