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

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

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

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

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

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,

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

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) {

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

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

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

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.

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

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

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

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

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

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