I like the idea, but the thing is, middleware is not the end-all of this
approach.
What might be missing is:
interface Resource {
public function response(ServerRequestInterface $request):
ResponseInterface
}
I use this in my framework I'm building as anything that provides a
response from a request, like a Page (Controller).
This of course could also be used for middlewares as you stated.
Is it worth it to split up all these PSR's with just for the benefit of
having different names of the interface?
I don't know, maybe it is, to me it seems more and more like it doesn't.
Den onsdag 17 maj 2017 kl. 22:59:15 UTC+2 skrev Rasmus Schultz:
>
> I think he was describing the other interfaces that are part of that
> proposal. (?)
>
> Since these aren't directly related to the problem at hand, and could be
> specified in a separate PSR, I'm rooting for a separate PSR for just the
> handler interface.
>
>
> On May 17, 2017 19:03, "Larry Garfield" <la...@garfieldtech.com
> <javascript:>> wrote:
>
>> On 05/17/2017 09:40 AM, Beau Simensen wrote:
>>
>> On Wednesday, May 17, 2017 at 12:42:29 AM UTC-5, Rasmus Schultz wrote:
>>>
>>> I think it's great that you're coming around to the idea, Woody :-)
>>>
>>> But I am no longer trying to view this as an alternative to PSR-15,
>>> because, assuming we standardize on that handler-interface first, there is
>>> nothing about PSR-15 that prevents us from exploring other options.
>>>
>>
>> Indeed, if the end result of this discussion is extracting
>> DelegateInterface into its own proposal as its own handler interface that
>> can be used as the delegate in PSR-15, I'm happy with that.
>>
>>
>> I'm still a bit unclear on the "handler" as an uber-generic thing. Isn't
>> that entirely separate from what Woody described, which is a 3-part
>> pipeline? (Request modifiers, response modifiers, and request->response
>> mappers.)
>>
>> I admit the 3-part pipeline is appealing, and I've considered it before.
>> I especially like that it keeps a shallower call stack. However, the
>> problem is conditional request modifiers. Eg, an Auth modifier that may:
>>
>> 1) Add a user token to the request based on authentication.
>> 2) Fail authentication and short circuit the entire pipeline with a
>> 401/403 Response itself.
>>
>> If the signature only allows returning a Request, then it can't do that.
>> It has to be a nested mapper instead and do the delegate approach anyway.
>> And if it's doing that anyway... what's the purpose of having the separate
>> modifiers if they can't be used half the time anyway?
>>
>> I'm afraid I'm still confused here about what is being proposed and what
>> it solves...
>>
>> --Larry Garfield
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/php-fig/B3jtdJA7-6w/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> php-fig+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to php...@googlegroups.com
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/b7a62479-e587-c7a7-7f1d-b5ddc3464a7d%40garfieldtech.com
>>
>> <https://groups.google.com/d/msgid/php-fig/b7a62479-e587-c7a7-7f1d-b5ddc3464a7d%40garfieldtech.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
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/d281d8b5-ce87-49c0-9b26-038dd9c27e07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
