Hey Beau, Thanks a lot for your detailed posts.
You understood my idea completely and you are expressing (in better words) exactly what I wanted to suggest. I take my hat of to you. Also, you are 100% right in the critics you make. Indeed, middleware authors would have to write 2 classes (one middleware and one factory). You are also right to state that the factory class is mostly a boilerplate class with a constructor that takes the same arguments as the middleware, except the "next" middleware that is provided at runtime to the factory. I've been looking for ways to write a "generic" factory, but to do this, we have to go back to a convention (like in Stack) so I've not yet found something sexy enough to speak about it. Anyway, I'm glad I could help move the discussion forward. I completely forgot to state it but I have really no strong feeling about which way PSR-15 go. I'm really ok with the way PSR-15 is right now. I understand what Rasmus says regarding the fact that not all middlewares need a "next" delegate (or that some need more than one). I would be glad if we can find a way to improve this, but I also understand Beau whan he says he does not want this to be at the expense of simplicity (my proposal requires writing 2 classes and only one class to write is a plus as it will help widen adoption). It looks to me like so far, unless we can come up with a better idea, there is a tradeoff to be done. Whatever way this is going, I'll be happy ;) ++ David. Le lundi 15 mai 2017 02:43:27 UTC+2, Beau Simensen a écrit : > > On Sunday, May 14, 2017 at 11:13:46 AM UTC-5, Rasmus Schultz wrote: >> >> > the middleware themselves cannot be autowired and *must* be created >> manually by the factory. >> >> Are you highlighting this as a problem? >> >> Of course the factory would need to create the middleware - that's what a >> factory is for. (?) >> > > I think there is confusion between your solution and the middle-ground > David was proposing. I had hoped I kept that post more clear but it appears > I failed. :( My bad. > > First, yes, it is a problem because a middleware that could previously be > autowired can now only be created manually by a factory, even though the > middleware has not changed much at all. > > Second, with the existing proposal we don't need a factory. Yes, David's > proposal has a factory so yes, obviously, it should be used to create the > middleware. If we ended up going with something like David proposed, I do > not disagree that this is where the middleware should be created. :) > > My entire set of example code was intended to show what would happen to > one of my real world middleware if we implemented Davdi's proposal. > > > >> > At the end of the day it comes down to whether the delegate/next of a >> middleware should be a runtime dependency or an instance dependency. I >> think that is the core of what Rasmus is exploring here. It seems like he >> has decided it should not be a runtime dependency >> >> I don't feel it's a decision so much as a conclusion. >> >> I'd like it not to be the case, because it would surely be simpler, but >> the fact is that there isn't always precisely one delegate - which leads me >> to conclude it can't be a runtime dependency, or at least not if you want >> the model to reflect reality, which is something I always strive for. >> > > This is the same reasoning I would use to argue for why the delegate > should be a runtime dependency. There is never precisely one delegate. The > state that is important at the point in time that the middleware is > executed is the request and the delegate. The middleware instance itself > does not depend on the delegate any more than it does on the request. > > > >> > I'm not happy about the idea that every middleware is going to >> effectively require two classes be written >> >> Let's explore that problem. >> >> I think, first of all, you need to not think of this as "middleware >> consisting of two classes" - it's really two different classes, one is a >> handler, the other is middleware: they have different purposes in different >> contexts. >> > > Again, this line of thought was directly related to David's proposal. > > I'm confused by what you said here, though, so maybe you can elaborate. > Not sure if this is talking about something else or about David's proposal > or....? > > What I had said was not that "middleware would consist of two classes", > but that "writing middleware would require writing two classes." Since this > was about David's proposal, this was a factory and a middleware. Where I > previously had one middleware class, it turned into a middleware class and > a factory class. The example I shared showed the BEFORE code with one > MiddlewareInterface implementation and AFTER showed two classes, a > MiddlewareFactoryInterface and a MiddlewareInterface. > > What you said is something different. What do you mean by "one is a > handler, the other is a middleware?" Also, "they have different purposes in > different contexts." Can you show me what that looks like using the example > code I shared with BEFORE / AFTER on the User ID metadata enricher > middleware? Because I'm starting to wonder if I've completely missed > something major here. Probably easiest to just start with the simple BEFORE > middleware and then I'd be able to compare against what I came up with for > my AFTER to see if I can follow this better. > > > >> If the only problem is deferring the loading and creation of handlers, >> and the issue is "not knowing" which constructor-argument is the delegate, >> maybe we could solve this by marking that argument somehow... >> > > I think that has been the biggest sticking point for me. We never had a > good solution for this for Stack except for the conventions that allowed > Stack Builder to be successful. It suffered drawbacks as discussed > previously in this thread. > > If this bit of code is doing what I think it is, it might be an > interesting idea: > > > https://bitbucket.org/mindplaydk/middleware-experiment/src/d5c26eba9e445f2f9d2b9f3fd8ee465812c2ab0c/src/Dispatcher.php?at=master&fileviewer=file-view-default#Dispatcher.php-49 > > The only problem is that I'm not sure how many containers would support > this. I *think* this is the first time I've seen this in a container. > > > > I'm still hung up on the runtime dependency vs not. I don't agree with the > conclusion. That doesn't mean I cannot be convinced otherwise. :) > > I think I'm starting to better understand what you're getting at, though. > Is this an accurate summary of your conclusion? > > The only difference between a handler and a middleware is the delegate. If > we can find a way to remove the delegate from the handler method entirely, > then there is no difference between the two as far as `handle(req) : res`. > > > -- 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/a48f9e36-b994-419f-a35e-f721cc9475c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
