Re: PSR-7 Alternate Proposal

> > I am proposing that we really look at what the requirement is here, and > come up with something that fits the bill properly, rather than rehash > previous principles that smell bad. > > [...] `interface MiddlewareInterface {}` [...] > > We need a base interface that can allow type hinting a

Re: PSR-7 Alternate Proposal

Hi Josh, I've been having a good old think about what you asked, as it confused me a little being that I don't code that way myself. To me, exception handling, to be effective, should happen at your application level, not at such a low level as middleware; in my applications, the function call

Re: PSR-7 Alternate Proposal

Please point me to examples that I can replicate, otherwise I can't answer your questions accurately. Thanks On Wednesday, 22 February 2017 11:13:26 UTC, Josh Di Fabio wrote: > > Hi John, > > How would you implement a middleware which catches an exception thrown by > an inner middleware and ret

Re: PSR-7 Alternate Proposal

Hi John, How would you implement a middleware which catches an exception thrown by an inner middleware and returns a response instead of allowing the exception to bubble up? On Wed, Feb 22, 2017 at 11:06 AM Michael Mayer wrote: > John, would you mind pushing your interfaces and Stack to github?

Re: PSR-7 Alternate Proposal

John, would you mind pushing your interfaces and Stack to github? Thus, everybody interested can play with your code, which probably would reduce mails here. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscrib

Re: PSR-7 Alternate Proposal

John, while I appreciate your passion, I should remind you that this is a mailing list, not a chat room, so could you please throttle yourself? We usually try to keep a soft limit of 2 posts per thread per day. Thanks. -- You received this message because you are subscribed to the Google Groups

Re: PSR-7 Alternate Proposal

And I forgot to return $response in the parseResponse function. Not doing great here am I? On Tuesday, 21 February 2017 21:57:20 UTC, John Porter wrote: > > Obviously I would have remembered to rename my example class there if I > weren't about to go to bed. > > Catch you all tomorrow! > > On Tu

Re: PSR-7 Alternate Proposal

Obviously I would have remembered to rename my example class there if I weren't about to go to bed. Catch you all tomorrow! On Tuesday, 21 February 2017 21:55:24 UTC, John Porter wrote: > > I was right about the prototype issues, my tests have been fixing those. > > Here's my interpretation then

Re: PSR-7 Alternate Proposal

I was right about the prototype issues, my tests have been fixing those. Here's my interpretation then of of the ResponseTime middleware: getServerParams(); $this->startTime = isset($server['REQUEST_TIME_FLOAT']) ? $server[ 'REQUEST_TIME_FLOAT'] : microtime(true); } public functi

Re: PSR-7 Alternate Proposal

Am Dienstag, 21. Februar 2017 20:50:10 UTC+1 schrieb John Porter: > > Can you explain what you mean by prototype related issues? > I only see some issues with your code which are unrelated to your idea, that's all. Where would the computation time be added, to a request or response? Can > you s

Re: PSR-7 Alternate Proposal

Could you be a little more clear for me? Can you explain what you mean by prototype related issues? Also, to aid me in showing accurate examples: Where would the computation time be added, to a request or response? Can you show me how you’d achieve it with the double pass method, and I can show

Re: PSR-7 Alternate Proposal

Ok, despite some prototype related issues, I do not understand how you want to stack multiple RequestMiddlewareInterface instances? For example one which adds the computation time, but only if the next middleware (e.g. the AuthHeaderMiddleware) returned with status === 200. On Tuesday, Februa

Re: PSR-7 Alternate Proposal

Woody, Here's an example meeting your criteria (I think): getMethod() === 'POST' && $request->hasHeader( 'authorization')) { return $request; // Passthrough here } $response = $this->createResponseInstance(); return $response->withStatus(401); // short circui

Re: PSR-7 Alternate Proposal

Here's the code I'm testing at present (I know, i know, TDD!) Some of the interface names are obviously wrong but are the same as I proposed earlier. stack = $stack; $this->factory = $factory; } public function addMiddleware(MiddlewareInterface $middleware) { $this->

Re: PSR-7 Alternate Proposal

The methods called in the example aren’t right though, but the premise is accurate. On 21 February 2017 at 18:37:21, John Porter (j...@designermonkey.co.uk) wrote: That’s the most accurate description thus far Larry, yes. Why can’t I write that simply eh? :) On 21 February 2017 at 18:27:56,

Re: PSR-7 Alternate Proposal

That’s the most accurate description thus far Larry, yes. Why can’t I write that simply eh? :) On 21 February 2017 at 18:27:56, Larry Garfield (la...@garfieldtech.com) wrote: If I am following you, your issue is more that you would want to see three different types of middleware: Passthrough a

Re: PSR-7 Alternate Proposal

If I am following you, your issue is more that you would want to see three different types of middleware: Passthrough a request (with modification), turn request to response, and passthrough response (with modification). Is that more accurate? The core of a middleware dispacher would then be:

Re: PSR-7 Alternate Proposal

Sadly, I have not explained very well have I, as no one seems to grasp what I am on about. The middleware does not need to know about the exchange at all, it is only responsible for receiving a Message and returning a Message. I am currently coding up the example to show you all. Woody, for yo

Re: PSR-7 Alternate Proposal

As far as I can see, the essential difference between PSR-15 and your proposal is about the responsibility for dispatching the next middleware: 1. with your version: it is determined at *compile time*, by implementing the appropriate interface; thus the stack should be responsible for it only. 2.

Re: PSR-7 Alternate Proposal

On Tue, Feb 21, 2017 at 9:23 AM, John Porter wrote: > the stack should handle iteration and short-circuits Okay, let's test this theory. You have a requirement that all incoming POST requests contain a `Authoriation: Token ` header. How do you respond with `HTTP 401` in this scenario? -- Woody

Re: PSR-7 Alternate Proposal

Yes. As I've explained in the proposal, the stack should handle iteration and short-circuits, not each middleware. This is the reason there are two interfaces; one for request and one for response. On Tuesday, 21 February 2017 15:14:25 UTC, Woody Gilk wrote: > > > On Tue, Feb 21, 2017 at 8:41 AM

Re: PSR-7 Alternate Proposal

On Tue, Feb 21, 2017 at 8:41 AM, John Porter wrote: > the one fundamental thing I want to help try and avoid is having one > single function in a Middleware instance be in control (so to speak) of the > middleware process. Does this mean you want to remove the middleware dispatcher? -- Woody G

Re: PSR-7 Alternate Proposal

Ok. Getting rid of all the solid fluff that is in the way, the one fundamental thing I want to help try and avoid is having one single function in a Middleware instance be in control (so to speak) of the middleware process. On Monday, 20 February 2017 02:36:20 UTC, Korvin Szanto wrote: > > Hi E

Re: PSR-7 Alternate Proposal

Hi Everyone, On Sun, Feb 19, 2017 at 2:04 PM John Porter wrote: > Hi Michael, > > Thanks for your response. I have read about, and personally discussed the > SOLID principles with Uncle Bob, and I do believe that there is more than > one final interpretation of those principles. I can see your p

Re: PSR-7 Alternate Proposal

Hi Michael, Thanks for your response. I have read about, and personally discussed the SOLID principles with Uncle Bob, and I do believe that there is more than one final interpretation of those principles. I can see your points, but raise you this: SRP says only that a `car` class should not i

Re: PSR-7 Alternate Proposal

Hi John, many thanks for your contribution. But as far as I can see, there is a big misconceptions about single responsibility principle (SRP) and interface segregation principle (ISP)

PSR-7 Alternate Proposal

I've re-read everything that was discussed in my last issue #46 and I realise that having an example of an alternative that fixes my myriad of concerns over swapping one flawed implementation for another (no offence meant), is prefer