closes https://github.com/middlewares/utils/issues/22

Should I send also migration from Travis to GitHub actions? Since Travis is ultra-slow these days and obviously does not have PHP 8.0 ready, GitHub actions are far better nowadays.

After thinking about #2 I came up with a bit more complex solution. This solution completely delegates the resolution to one or other resolver, allowing to support resolver specific features (like service id based resolution with a container).

In case the callable returns a non string-friendly value (not scalars, arrays, objects without __toString, etc) this line will produce a warning: https://github.com/middlewares/utils/blob/master/src/CallableHandler.php#L36

In that case we should throw an exception, because it's not responsibility of this class to make decisions about how to convert them to string, or delegate that (somehow) to next middleware like "I don't know what to do with this".

Hi. Thank you for the great libraries.

What do you think about making Middlewares\Utils\Dispatcher to implement Psr\Http\Server\RequestHandlerInterface?

Dispatcher already has method dispatch(ServerRequestInterface $request): ResponseInterface, that, except the name, resemble handle(ServerRequestInterface $request): ResponseInterface from RequestHandlerInterface.

Making Dispatcher a middleware composite enables to pass it to some runners, for example zendframework/zend-httphandlerrunner:

$runner = new RequestHandlerRunner(
    $container->get(ApplicationRequestHandler::class),
    $container->get(EmitterStack::class),
    $container->get('ServerRequestFactory'),
    $container->get('ServerRequestErrorResponseGenerator')
);
$runner->run();

What do you think about this?

I have tested such approach localy, so can provide PR if needed.

Thak you in advance.

https://github.com/zendframework/zend-diactoros states :

Repository abandoned 2019-12-31

This repository has moved to laminas/laminas-diactoros.

We should replace

const DIACTOROS = [
    'request' => 'Zend\Diactoros\RequestFactory',
    'response' => 'Zend\Diactoros\ResponseFactory',
    'serverRequest' => 'Zend\Diactoros\ServerRequestFactory',
    'stream' => 'Zend\Diactoros\StreamFactory',
    'uploadedFile' => 'Zend\Diactoros\UploadedFileFactory',
    'uri' => 'Zend\Diactoros\UriFactory',
];

with

const DIACTOROS = [
    'request' => 'Laminas\Diactoros\RequestFactory',
    'response' => 'Laminas\Diactoros\ResponseFactory',
    'serverRequest' => 'Laminas\Diactoros\ServerRequestFactory',
    'stream' => 'Laminas\Diactoros\StreamFactory',
    'uploadedFile' => 'Laminas\Diactoros\UploadedFileFactory',
    'uri' => 'Laminas\Diactoros\UriFactory',
];

Slim 4 now no longer has it's PSR-7 implementation bundled. It's now at https://github.com/slimphp/Slim-Psr7.

But slim/psr7 0.6 requires php ^7.1 though, which causes PHP 7.0 tests failed.

This PR fixes #5 by stating that middleware/utils 0.13+ should not be used if "http-interop/http-middleware" is used. This will force a fallback to older versions of middleware/utils.

Hey @oscarotero,

Version v0.13.0 of middleware/utils is wreaking havok on previous versions of all your middleware/* packages.

Here is the issue I am facing.

I'm using your middleware/whoops package. I'm stuck with v0.4.1 because I'm using http-interop/http-middleware v0.4 in my own middlewares.

Everything was working flawlessly until you introduced v0.13.0 of middleware/utils.

The problem:

v0.13.0 removes "http-interop/http-middleware": "^0.5". https://github.com/middlewares/utils/commit/296dc6129e934ac0db20f279d962cad46226cde3

Because of this, middleware/whoops v0.4.1 becomes compatible with middleware/utils v0.13.0.

When I install middleware/whoops v0.4.1, I'm installing middleware/utils v0.13.0, instead of middleware/utils v0.11 (which is the latest compatible version).

I see 2 possible ways to solve this problem.

Solution 1:

• add a conflict section to your composer.json to state that middleware/utils conflicts with "http-interop/http-middleware": "*".

It's easy, but it will only solve the problem if you remove the v0.13.0 tag from middleware/utils. Not very clean, but possible.

Solution 2:

• Go through all your packages, all tags and change the dependency from "middleware/utils": "~0.8" to "middleware/utils": ">=0.8 <0.13"

It's cleaner but it requires a hell lot more work to solve.

Whatever solution you choose, I'll be happy to contribute PRs.

• Updated the composer require-dev section to laminas
• Updated the Tests to the Laminas namespace
• Updated the Factory Discovery to the Laminas namespace

https://github.com/middlewares/utils/blob/7ad4e140ea96ba667603ac6a3f5650ccb838f3de/src/Factory/GuzzleFactory.php#L29

https://github.com/middlewares/utils/blob/7ad4e140ea96ba667603ac6a3f5650ccb838f3de/src/Factory/SlimFactory.php#L30

I am trying to register a route with fast route using an Object and static method with the following code:

static public function registerRoute( RouteCollector &$r ): void {
  $r->addRoute(['GET', 'OPTIONS'], '/password', array( self::class, 'renderChallenge') );
}

instead of the handler being called I instead get the following error message:

Argument 1 passed to Middlewares\Utils\CallableHandler::__construct() must be callable, object given, called in /src/vendor/middlewares/utils/src/RequestHandlerContainer.php on line 51

In the course of trying to debug I decided to test if what I was passing was callable using the following:

// Regular function to check if something is callable
function isThisCallable( callable $callable  ) {
    call_user_func( $callable );
}

// Modified code from above
static public function registerRoutes( RouteCollector &$r ): void {
    $r->addRoute(['GET', 'OPTIONS'], '/password', function() {
       isThisCallable( array(static::class, 'renderChallenge') );
    } );
}

This test code ran as expected and called the static object's method. Is this a bug or is there another way I should be passing an object and method as the handler?