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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b2059674-b35a-428a-8a3a-5865a778cea6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
