weierophinney

[RFC] zend-expressive-router (and related) changes for Expressive 1.1.

Proposed zend-expressive-router changes include:

• Adding a $path parameter to RouteResult::fromRouteMatch().

  What if instead we were to add a new static method, RouteResult::fromRoute(), and a new instance method, RouteResult::getRoute()? (as I have suggested in zendframework/zend-expressive#398)? This would allow consumers to then pull the path from the Route instead, and provide access to the path, name, allowed methods, options, etc. (e.g., $result->getRoute()->getPath())

  This could even be done in a new 1.3.0 minor release; users who depend on that new feature would need to update their project to pin to the new minor release or later; otherwise, everything continues working as normal.

weierophinney

[Expressive] RFC: Programmatic pipelines

When we originally created the API for Expressive, it was programmatic:

We had pipelines:

$pipeline->pipe($loggingMiddleware);
$pipeline->pipe($serverUrlHelperMiddleware);
$pipeline->pipeRoutingMiddleware();

weierophinney

[zend-stratigility] RFC: Implement PSR-15

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:

weierophinney

[zend-stratigility] RFC: Remove request, response decorators

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.

These are used internally specifically in the FinalHandler, but nowhere else. If the proposal to remove the FinalHandler and error middleware is approved, there is no longer an internal use case for them.

weierophinney

[zend-stratigility] RFC: Remove FinalHandler, ErrorMiddlewareInterface

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.

weierophinney

<?php
// config/autoload/db.global.php
$provider = new Zend\Db\ConfigProvider();
return $provider();

weierophinney

<?php
use Zend\Expressive\Container\ApplicationFactory;
use Zend\Expressive\Helper;

return [
    'middleware_pipeline' => [
        'always' => [
            'middleware' => [
                Helper\ServerUrlMiddleware::class,
            ],

weierophinney

I received this comment on twitter earlier today, in response to zendframework/zend-mvc#89 (comment)

"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,

weierophinney

How to test zend-mvc 2.7.0

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.

weierophinney

Benchmarks from current v2 master.

ZendBench\EventManager\MultipleEventIndividualSharedListener
    Method Name   Iterations   Average Time      Ops/second
    ------------ ------------ ----------------- -------------
    trigger    : [     5,000] [0.0001748194695] [5,720.18668]


ZendBench\EventManager\MultipleEventLocalListener
    Method Name   Iterations   Average Time      Ops/second