Closed designermonkey closed 9 years ago
I was also wondering why the Middleware
part has been removed from namespace. It kind of makes sense to keep it there.
Largely because middleware is application specific and the Middleware class has been deprecated.
I understand the class has been deprecated, what I'm talking about is the namespace, hence the title [v3] Middleware Namespace
.
It makes for better structural organisation to hold them in a namespace, whether they're in the core package or not.
I can see the logic for the Slim 3 compatible Middleware components to be in the Slim\Middleware
namespace
From what I can see we currently don't have any Slim 3 specific middleware at the moment, I think Session will be the first and probably will use the Slim\Middleware
namespace.
Why is the Session middleware Slim-specific?
Well it wont be but it needs a namespace to live under as a Middleware.
Slim-HttpCache is Middleware
I still stand firm on all middleware should be contained in the application namespace.
@akrabat didn't see that one.
On a separate note can we stop coupling the ServiceProvider with the actual code for the package. I see this is becoming a pattern that others will follow. Now that we are using Container Interop, we shouldn't bind the actual package to the Pimple ServiceProviderInterface, we should create a separate class in each package to do this.
I agree about the ServiceProvider coupling.
This starts to be academic, but stirring it a bit more. If middlewares are not Slim specific why are they under Slim namespace then? It is matter of taste but Slim\Middleware\HttpCache
sounds more logical to me than Slim\HttpCache\Cache
.
Is there a practical reason why Slim middleware should not be under Slim\Middleware
namespace? Other than ones preferred way of naming things?
I think its more of an identity to say where they came from and I guess to also lessen collision. But I do agree that it should be under Slim\Middleware
namespace in order to not convolute the top level namespace.
The top level namespace is for vendor, so all of this organisation's PHP projects should be under the Slim
top level namespace regardless of whether they are Slim specific or not.
I think that everyone other than geggleto agrees that any middleware that the organisation creates should be in the Slim\Middleware
namespace.
What about middleware not maintained in the slimphp organization? Could I still use the Slim\Middleware namespace to organize my own code?
As a rule, you should use your own top level namespace for your code. e.g. I use RKA
or Akrabat
Yep. Choose a top-level vendor namespace that is unique to you.
Would it be wise to provide all Slim 'core' middleware packages under a specific namespace?
for example.