You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PSR-15
proposes a standard around PHP middleware that consumes
PSR-7 HTTP message instances. One goal of
the standard is to create interfaces that can co-exist with existing projects,
which would allow adoption without necessarily leading to backwards
compatibility breaks.
The most recent proposal has the following interfaces:
The FinalHandler concept in zend-stratigility comes essentially whole cloth from Sencha Connect (with the primary difference being the arguments passed to it). It's unique in the PHP ecosystem, and provided an early, catchall way to handle both 404 conditions and server errors.
However, it also introduces some cognitive overhead, does not play well with middleware-based error handling, and can lead to unexpected results due to how pipeline ordering works once an error handler is invoked.
The idea I present is to do the following:
Remove the FinalHandler class entirely.
Rename the $out argument to $next in both MiddlewareInterface and MiddlewarePipe::__invoke(); additionally, make it required.
Currently, we have a Zend\Stratigility\Http namespace that contains:
Request, a decorator for PSR-7 requests that provides access to the original request instance at server invocation.
ResponseInterface, which provides the methods write(), end(), and isComplete().
Response, which decorates a PSR-7 response to provide access to the original response instance at server invocation, and implements the above ResponseInterface.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Using the zend-db ConfigProvider within a zend-expressive application
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Please help me with a tricky git component split problem
UPDATE: I discovered the issue is with specifying a commit range to filter-branch. When that is omitted, everything works perfectly, including history truncation! Thanks to everyone who assisted with ideas and suggestions!
I am currently working on a project to split the various components of Zend
Framework 2 into their own repositories.
Currently, our repository structure looks like this:
Alternate way to push middleware into the pipeline between routing and dispatch.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
"recommended for literally years developers not [lazy load]" - official Zend certification taught it depends on situation!
To this, I have two responses.
When was the certification created?
The certification was created within the first year of the first ZF2 stable
release, and is current to ZF 2.2.0. That release was almost three years ago,
We're prepping a 2.7.0 release of zend-mvc. It has a few features of interest:
New middleware dispatcher to allow dispatching PSR-7 middleware from within the zend-mvc workflow.
Updates to be forwards-compatible with v3 components.
This latter has been the result of a months of work getting all the components zend-mvc depends on updated,
and then updating the plethora of factories, event listeners, and places where events are triggered exposed
by zend-mvc to work across both the v2 and v3 versions of zend-servicemanager and zend-eventmanager.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters