With the release of Expressive 2, one of the key stories was the ability to require ZF components within Expressive, and have their dependencies auto-wired into your application courtesy of the component installer.
However, we recently had a user in our Slack channel (need an invite?) indicating they were having issues with usage of custom validators, filters, and input filters. After a more thorough writeup on our forums, I realized we'd missed something important when making these integrations, and set out to solve it.
In zend-mvc applications, zend-modulemanager aggregates
registered with the application, and, in the process, does things like merge all
configuration. One thing it also does is seed plugin managers. The process for
this is rather convoluted, as it uses a combination of configuration keys as
well as methods defined in
Module classes in order to pull together all
configuration for a given plugin manager prior to initializing it.
What this means is that, in most cases, components can have a specific configuration key they look under for service definitions specific to a given plugin manager. As an example, for zend-filter, you might do something like:
[ 'filters' => [ 'aliases' => [ /* ... */ ], 'invokables' => [ /* ... */ ], 'factories' => [ /* ... */ ], 'delegators' => [ /* ... */ ], ], ]
All plugin manager configurations follow the same format, but use a different top-level key.
The problem we ran into in Expressive is that while we have encouraged users to do this, the plugin managers were never seeded with this configuration, as the logic for that was relegated to zend-modulemanager integrations!
Over the past few days, I identified seven affected components, and wrote patches for each that fix the problem. What they do is check to see if a zend-modulemanager-specific service is present, and, if not, they then check for and pull the relevant configuration, and use it to configure the plugin manager.
The following releases now have these fixes:
log_formatterskeys for configuring the
translator_pluginskey for configuring the
hydratorskey for configuring the
filterskey for configuring the
validatorskey for configuring the
input_filterskey for configuring the
form_elementskey for configuring the
The end result is that each of these components will now work with Expressive out of the box just as they would in a zend-mvc application!
I feel this is a huge step forward in usability of Expressive; in fact, each of these components can now be more easily used in any application, which is a huge win. I'm hoping that with these releases, folks will start evaluating them more seriously for inclusion in other middleware architectures as well.
This problem would likely have not been identified as quickly without the new community process and tools we now have in place. A Slack thread helped identify a problem existed, and a forum post helped us get all the details necessary to reproduce the issue, and then coordinate the patches.
Save the date!
Want to learn more about Expressive and Zend Framework? What better location than ZendCon 2017! ZendCon will be hosted 23-26 October 2017 in Las Vegas, Nevada, USA. Visit the ZendCon website for more information.
Subscribe to this blog via RSS.