zendframework/zend-mvc
Zend\Mvc is Zend Framework’s MVC layer for building PHP web apps. It provides routing, controllers, dispatching, request/response handling, view integration, and an event-driven pipeline. Designed for modular apps and flexible configuration.
#217 adds support for
middleware pipelines when using the MiddlewareListener. You can now
specify an _arrayof middleware for themiddlewareattached to a route, and it will be marshaled into aZend\Stratigility\MiddlewarePipe` instance, using
the same rules as if you specified a single middleware.
#236 adds the ability to
attach dispatch listeners to middleware when using the MiddlewareListener.
Attach shared events to the class identifier Zend\Mvc\Controller\MiddlewareController.
This feature helps ensure that listeners that should run for every controller
(e.g., authentication or authorization listeners) will run even for
middleware.
#231 adds a
composer.json suggestion for zendframework/zend-paginator.
#232 adds a
composer.json suggestion for zendframework/zend-log.
HttpDefaultRenderingStrategyFactory::createService and
injectLayoutTemplate() to be HttpDefaultRenderingStrategy and not
HttpDefaultRendererStrategy.RouteMatch and its parameters to the PSR-7 ServerRequest object so that
they are available to middleware.SendResponseListener, to ensure that it is injected with an event
manager instance from the outset; this fixes issues with delegator factories
that registered listeners with it in previous versions.#163 adds support to the
AcceptableViewModelSelector plugin for controller maps in the view_manager
configuration in the format:
[
'ControllerClassName' => 'view/name',
]
This fixes an issue observed when running with Apigility.
#163 adds support to the
InjectTemplateListener for specifying whether or not to prefer the
controller matched during routing via routing configuration:
'route-name' => [
/* ... */
'options' => [
/* ... */
'defaults' => [
/* ... */
'prefer_route_match_controller' => true,
],
],
],
This allows actions that might otherwise skip injection of the template to force the injection.
DispatchListener::marshalBadControllerEvent() method to allow either
Throwable or Exception types for the $exception argument.#165 adds a new
controller factory, LazyControllerAbstractFactory, that provides a
Reflection-based approach to instantiating controllers. You may register it
either as an abstract factory or as a named factory in your controller
configuration:
'controllers' => [
'abstract_factories' => [
'Zend\Mvc\Controller\LazyControllerAbstractFactory`,
],
'factories' => [
'MyModule\Controller\FooController' => 'Zend\Mvc\Controller\LazyControllerAbstractFactory`,
],
],
The factory uses the typehints to lookup services in the container, using
aliases for well-known services such as the FilterManager,
ValidatorManager, etc. If an array typehint is used with a $config
parameter, the config service is injected; otherwise, an empty array is
provided. For all other types, a null value is injected.
New major version! Please see:
for full details on how to migrate your v2 application.
Zend\Mvc\Router namespace. This
functionality is now provided by the zend-router
component, which becomes a requirement of zend-mvc. The removal also includes
all service factories related to routing, as they are provided by zend-router.AbstractConsoleController, the
CreateConsoleNotFoundModel controller plugin, the ConsoleResponseSender,
and all classes under the Zend\Mvc\View\Console namespace; these are now
provided by the zend-mvc-console
component. (That component also includes console-specific routes, which were
removed from zend-router.) All service factories related to console
functionality are also now provided by zend-mvc-console.prg()
plugin. It can now be installed separately via the
zendframework/zend-mvc-plugin-prg package.fileprg(), flashMessenger(), and identity() plugins. These can be
installed via, respectively, the zendframework/zend-mvc-plugin-fileprg,
zendframework/zend-mvc-plugin-flashmessenger, and
zendframework/zend-mvc-plugin-identity packages.zendframework/zend-mvc-i18n will restore i18n functionality in
your application.InjectTemplateListener by inlining the
logic from Zend\Filter\Word\CamelCaseToDash.FilterPluginManager. That functionality is now exposed directly by the
zend-filter component.ValidatorPluginManager. That functionality is now exposed directly by the
zend-validator component.SerializerAdapterManager. That functionality is now exposed directly by the
zend-serializer component.HydratorManager. That functionality is now exposed directly by the
zend-hydrator component.$configuration argument (first required argument) from the
Zend\Mvc\Application constructor. If you were directly instantiating an
Application instance previously (whether in your bootstrap, a factory, or
tests), you will need to update how you instantiate the instance. (The
argument was removed as the value was never used.)ProcessorPluginManager and WriterPluginManager. That functionality is now
exposed directly by the zend-log component (with the addition of exposing the
FilterPluginManager and FormatterPluginManager as well).InputFilterManager. That functionality is now exposed directly by the
zend-inputfilter component.FormElementManager, FormAnnotationBuilder, and the
FormAbstractServiceFactory. The functionality is now exposed directly by the
zend-form component.ViewHelperManager factory for fetching configuration
classes from other components and using them to configure the instance. In all
cases, this is now done by the components themselves.ControllerLoaderFactory, and the ControllerLoader service alias; use
ControllerManagerFactory and ControllerManager, respectively, instead.Zend\Mvc\View\SendResponseListener; use Zend\Mvc\SendResponseListener
instead.Application::send(), which has been a no-op since 2.2.DispatchListener::marshallControllerNotFoundEvent(), which has proxied to
marshalControllerNotFoundEvent() since 2.2.ServiceLocatorAwareInterface implementation
(setServiceLocator()/getServiceLocator() methods) from
AbstractController. You will need to inject your dependencies specifically
going forward.ServiceLocatorAwareInterface initializers defined in
Zend\Mvc\Service\ServiceManagerConfig and
Zend\Mvc\Controller\ControllerManager. You will need to inject your
dependencies specifically going forward.__NAMESPACE__ routing
configuration option, as it often led to conflicts when multiple modules
shared a common top-level namespace. Auto-resolution now always takes into
account the full namespace (minus the Controller segment).AbstractRestfulController to make usage of zend-json for deserializing JSON
requests optional. json_decode() is now used by default, falling back to
Zend\Json\Json::decode() if it is available. If neither are available, an
exception is now thrown.Throwables within each of:
DispatchListenerMiddlewareListenerRouteNotFoundStrategy and ExceptionStrategyDefaultRenderingStrategy and RouteNotFoundStrategyFormAnnotationBuilderFactory to use the container's get() method instead
of build() to retrieve the event manager instance.ConsoleExceptionStrategyFactory whereby it was overwriting the default
exception message template with an empty string when no configuration for it
was provided.ServiceLocatorAware initializer whereby plugin manager instances were
falsely identified as the container instance when under zend-servicemanager v2.ServiceManager factory definition inside ServiceManagerConfig, to ensure
backwards compatibility.Zend\Mvc\Service\ServiceListenerFactory,
which were accidently removed in the 2.7.0 release.Forward plugin to work with both v2 and v3
of zend-eventmanager.Catchall route factory will not fail when the defaults $options
array key is missing.AbstractRestfulController to ensure it can accept textual (e.g., XML, YAML)
data.#88 addresses backwards
compatibility concerns raised by users due to the new deprecation notices
emitted by ServiceLocatorAware initializers; in particular, all
AbstractController implementations were raising a deprecation wen first
pulled from the ControllerManager.
At this time, notices are now only raised in the following conditions:
ServiceLocatorAware instance
is detected.ServiceLocatorAware and
does not have a composed service locator. In this situation, the deprecation
notice indicates that the factory for the plugin manager should be updated
to inject the service locator via the constructor.AbstractController but do implement
ServiceLocatorAware.getServiceLocator() from within an AbstractController
extension; this properly calls out the practice that should be avoided and
which requires updates to the controller.#31 adds three new
optional arguments to the Zend\Mvc\Application constructor: an EventManager
instance, a Request instance, and a Response instance.
#36 adds more than a dozen service factories, primarily to separate conditional factories into discrete factories.
#32 adds
Zend\Mvc\MiddlewareListener, which allows dispatching PSR-7-based middleware
implementing the signature function (ServerRequestInterface $request, ResponseInterface $response). To dispatch such middleware, point the
middleware "default" for a given route to a service name or callable that
will resolve to the middleware:
[ 'router' => 'routes' => [
'path' => [
'type' => 'Literal',
'options' => [
'route' => '/path',
'defaults' => [
'middleware' => 'ServiceNameForPathMiddleware',
],
],
],
]
This new listener listens at the same priority as the DispatchListener, but,
due to being registered earlier, will invoke first; if the route match does
not resolve to middleware, it will fall through to the original
DispatchListener, allowing normal ZF2-style controller dispatch.
#84 publishes the documentation to https://zendframework.github.io/zend-mvc/
Zend\Mvc\Service\ServiceManagerConfig are now
deprecated, and will be removed starting in version 3.0:
ServiceManagerAwareInitializer, which injects classes implementing
Zend\ServiceManager\ServiceManagerAwareInterface with the service manager
instance. Users should create factories for such classes that directly
inject their dependencies instead.ServiceLocatorAwareInitializer, which injects classes implementing
Zend\ServiceManager\ServiceLocatorAwareInterface with the service manager
instance. Users should create factories for such classes that directly
inject their dependencies instead.Zend\Mvc\Controller\AbstractController no longer directly implements
Zend\ServiceManager\ServiceLocatorAwareInterface, but still implements the
methods defined in that interface. This was done to provide
forwards-compatibility, as zend-servicemanager v3 no longer defines the
interface. All initializers that do ServiceLocatorInterface injection were
updated to also inject when just the methods are present.RouteInvokableFactory, which can act as either a
FactoryInterface or AbstractFactoryInterface for loading invokable route
classes, including by fully qualified class name. This is registered as an
abstract factory by default with the RoutePluginManager.DispatchListener now receives the controller manager instance at
instantiation.ViewManager implementations were updated, and most functionality
within separated into discrete factories.FormAnnotationBuilderFactory's usage of the
FormElementManager::injectFactory() method to ensure it works correctly on
all versions.ViewHelperManagerFactory to be backwards-compatible with v2 by ensuring that
the factories for each of the url, basepath, and doctype view helpers
are registered using the fully qualified class names present in
Zend\View\HelperPluginManager; these changes ensure requests for these
helpers resolve to these override factories, instead of the
InvokableFactory.#69 largely reverts
#30, having the component
utilize the HydratorPluginManager from zend-stdlib 2.7.5. This was done to
provide backwards compatibility; while zend-stdlib Hydrator types can be used
in place of zend-hydrator types, the reverse is not true.
You can make your code forwards-compatible with version 3, where the
HydratorPluginManager will be pulled from zend-hydrator, by updating your
typehints to use the zend-hydrator classes instead of those from zend-stdlib;
the instances returned from the zend-stdlib HydratorPluginManager, because
they extend those from zend-hydrator, remain compatible.
>=2.5.0,<2.7.0 to ensure hydrators
will work as expected following extraction of hydrators to the zend-hydrator
repository.DefaultRenderingStrategy.How can I help you explore Laravel packages today?