>
> What's a "non-response value"? You have "middleware" that doesn't return
> a Response object?
It was something I was playing with at the time. It worked fine w/ Relay as
Relay wasn't paying attention at all to what was returned from the
middleware.
This allowed actions run from the action handler middleware to return
values that were not response values that the view transformer middleware
could pick up. Provided the view transformer middleware was able to handle
whatever type object it got back from the delegate, it would transform it
into a response. The response assertion middleware would throw an exception
if a the response from its delegate was still not yet a ResponseInterface
instance.
This was experimental on my part. I remember talking to Matthew about it at
one point while I was working on it. I think it was an interesting idea but
definitely not a mainstream way to do things. I felt as long as my
framework was handling everything from ActionHandler to ResponseAssertion,
I'd be safe.
I'll be the first to say that not all of my ideas are the best ones. :)
I've since run into other middleware pipeline projects that ensure every
response is indeed a ResponseInterface instance. So I've adjusted this
behavior so that this work is done elsewhere. If I could apply this new
logic to the code I shared above, my stack would look like this:
NikicFastRoute::class, // routing
FixBrokenDiactorosCookieHeaderBehaviour::class, // workaround until a
cookie fix to diactoros could be tagged
CorsCompletelyOpenForDevelopment::class, // utility middleware that was
soon to be swapped for a better proper impl
UserAuthentication::class, // ensured that the request was made by an
authenticated user
OrganisationAuthorization::class, // ensured that the authenticated
user was authorized to access organisation resources
UserIdMetadataEnrichment::class, // used to ensure that the
authenticated user would be added to event envelopes
ActionHandler::class, // dispatcher
This goes into the discussion on creating a "handler" interface, I suppose.
Requiring the handler to always return a response object means that the
handler is going to have to do a lot. At the very least, the handler is
going to need to have a ResponseFactory injected into it. Having the option
to make my handlers support a hypothetical handler PSR would be nice, but I
would probably end up using ad-hoc handlers that could return
DTO/DomainObjects and have another layer that could convert those responses
into HTTP Responses. But I think that is a discussion for another thread at
this point.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAP75ejOAWsUQkbW%2BkZDR9ZLUbbV0xA1Ky%3DDqdahi%3D%3DgLvP2ymA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
