suggested by @oqq

not a bad idea... I now have one strategy that actually handles two kind of responses...

$responseStrategy = $this->responseStrategyFactory->createStrategyFromRequest($request);

return $responseStrategy->fromPromise(
    $this->queryBus->dispatch($query)
);

router config

 [
            'name'            => 'query::status-pong',
            'path'            => '/status/pong',
            'middleware'      => [
                QueryMiddleware::class,
            ],
            'allowed_methods' => ['POST'],
            'options'         => [
                'values' => [
                    QueryMiddleware::NAME_ATTRIBUTE => Status\QueryName::pong,
                    QueryMiddleware::PROMISE_TO_RESPONSE_STRATEGY => A/JsonResponse::class,
                ],
            ],
        ],

on chat

I'm thinking bout updating the middleware component to add support for queries on standard projections. Would that be useful?

sounds good

It is possible to query standard projections. One QueryStandardProjection query could do it, but we would loose out on permissions etc.. so... quick and dirty

trait StandardQueryTrait {
 public function streamName(): string {
    return $this->metadata()['stream_name'];
 }

 public function result($state) {
   return $state;
  }
}
abstract class QueryStandardProjection extends Messaging\Query implements Messaging\PayloadConstructable  {
   use Messaging\StandardQueryTrait;
}

class StandardQueryHandler {
    private $projectionManager;

    public function __construct(ProjectionManager $projectionManager)
    {
        $this-> projectionManager = $projectionManager;
    }

    public function onEvent(QueryStandardProjection $query, Deferred $deferred)
    {
        // use projectionManager to retrieve state of $query->streamName()

      $deferred->resolve($query->makeResult($state));
    }
}

class MyQuery extends QueryStandardProjection {
   public function result($state) {
     return ValueObject::fromArray($state);
  }
}

routes

        [
            'name'            => 'query::something',
            'path'            => '/path',
            'middleware'      => [
                StandardQueryMiddleware::class,
            ],
            'allowed_methods' => ['OPTION', 'GET'],
            'options'         => [
                'values' => [
                    StandardQueryMiddleware::NAME_ATTRIBUTE => MyQuery::class,
                    StandardQueryMiddleware::STREAM_NAME => 'my_projection',
                ],
            ],
        ],

Which add a StandardQueryMiddleware.

It's just an rough idea... Looking for input

@sandrokeil can you take a look why coveralls is not working? I've set everything up and travis-ci works/is green but coveralls status is unknown.

To add additional middleware to prooph routes one currently has to add those manually to each defined route.

eg.

[
  'name'            => 'query::support-doc::list-faqs',
  'path'            => '/support-doc/categories/{category_id}/faqs',
  'middleware'      => [
    JsonPayload::class,
    JsonApiProblem::class,
    ResourceServerMiddleware::class,
    JsonApiRequestMiddleware::class,
    ContentLanguageMiddleware::class,
    QueryMiddleware::class,
  ],
  'allowed_methods' => ['GET'],
  'options'         => ['values' => [QueryMiddleware::NAME_ATTRIBUTE => QueryName::listFaqs]],
],

We could introduce a way so QueryMiddleware and CommandMiddleware are capable of adding arbitrary middlewares so it can be easily configured.

I'm thinking of this configuration bit and some factory modifications;

    'prooph' => [
        'middleware' => [
            'query'   => [
                'response_strategy' => \HF\Api\ResponseStrategy\JsonApiResponseStrategy::class,
                'message_factory'   => \HF\Api\Messaging\QueryMessageFactory::class,
                'metadata_gatherer' => \HF\Api\Middleware\RequestMetadataGatherer::class,
                'middlewares'       =>
                    [
                        JsonPayload::class,
                        JsonApiProblem::class,
                        JsonApiRequestMiddleware::class,
                        ContentLanguageMiddleware::class,
                    ],
            ],
            'command' => [
                'response_strategy' => \HF\Api\ResponseStrategy\JsonApiResponseStrategy::class,
                'message_factory'   => \HF\Api\Messaging\CommandMessageFactory::class,
                'metadata_gatherer' => \HF\Api\Middleware\RequestMetadataGatherer::class,
                'middlewares'       =>
                    [
                        JsonPayload::class,
                        JsonApiProblem::class,
                        JsonApiRequestMiddleware::class,
                        ContentLanguageMiddleware::class,
                    ],
            ],
            ...
        ],
    ],

These 'middlewares' would need to be fetched from the container by Command and Query Factories and passed to the Command and QueryMiddlewares whom should process them in order and before the MetadataGatherer runs.

Shouldn't be too difficult, thoughts?

Hey guys,

I've just been following the prooph video tutorial over on youtube. Inside he's using the Psr7Middleware.

While using the most current Expressive default installation I'm running into the issue that the CommandMiddleware cannot be instantiated properly as it does not comform with the most current standard that is Psr\Http\Server\MiddlewareInterface.

Upon further inspection I assume this requires an update of the underlying package webimpress/http-middleware-compatibility as I do not see him handling the case inside the package.

Locally this can be solved by class_alias the CommandMiddleware to have the proper interface and structure but I suppose an update either here or on the side of webimpress should be done. If I am overlooking something please let me know, I'll gladly provide more info or PRs where required :)

Just come across this problem my self, read the docs and read that interop-config is required however it is only a development dependency.

https://github.com/prooph/psr7-middleware/blob/master/docs/book/factories.md#requirements point 2.
https://github.com/prooph/psr7-middleware/blob/master/composer.json#L56

It could be useful to get specific metadata from the psr7 request and create a command/event/query using the metadata. One example is an identity value object which was added by an authentication middleware to the request as an attribute.

One option would be to inject a "MetadataGatherer" (maybe optional dependency or a noop default) to each message handling middleware. The creation of a message could then look something like this:

$query = $this->queryFactory->createMessageFromArray($queryName, [
  'payload' => $payload,
  'metadata' => $this->metadataGatherer->getFromRequest($request),
]);

We should use the Interop\Http\ServerMiddleware\MiddlewareInterface (PSR-15).

Zend Expressive has a pretty nifty migration guide.

The docs from this repo don't show up on... http://docs.getprooph.org/

Can I help?

Hi!

Currently i see no clean way to provide some context metadata to response strategy.
As example it would be handy to use the request or the query that was dispatched to the query bus, to get the provided metadata.

final class HtmlResponseStrategy implements ResponseStrategy
{
    /** @var TemplateRendererInterface */
    private $templateRenderer;

    /**
     * @param TemplateRendererInterface $templateRenderer
     */
    public function __construct(TemplateRendererInterface $templateRenderer)
    {
        $this->templateRenderer = $templateRenderer;
    }

    /**
     * @inheritDoc
     */
    public function fromPromise(Promise $promise, array $context)
    {
        /** @var ServerRequestInterface $request */
        $request = $context['request'];
        $template = $request->getAttribute('template');

        $data = null;

        $promise->done(function($result) use (&$data) {
            $data = $result;
        });

        return new HtmlResponse(
            $this->templateRenderer->render($template),
            ['data' => $data]
        );
    }
}

Without $context i have create a abstract factory to inject the template name in the strategy, which would ends in a config nighmare.

Or am i missing a already existing solution for that issue?
Some hints would to be welcome.

Thanks!

Since there would be a new PSR for middlewares with identifier PSR-15 sone, we should rename this repo before a stable release.

Also this changes here: #34
uses the http-interop vendor. This should be changed to the final psr/http-server-middleware once it is available.

Is this something we should implement also? https://github.com/webimpress/http-middleware-compatibility.

like here: https://github.com/zendframework/zend-expressive-session/pull/2/files
or here : https://github.com/harikt/psr7-asset/pull/25/files

• prooph/psr7-middleware
• prooph/proophessor-do
• prooph/event-store-http-api

We should always call $next instead of returning the response directly to allow, that other middlewares can be executed after the prooph middlewares. Here is the rule

1. Return $response only if an error is occured
2. Otherwise call always $next with the new response

What do you think?