I think we should consider renaming RouteGroup to Prefix, I think currently there is confusion around the RouteGroup term as users kinda expect them to work like a Route. But in reality these are just prefixes to the path that gets generated for the route nested in them.
I want to propose for Slim 4 we remove the group() method and add a prefix() method instead. I think this more clearly states what it does.
I am also proposing we add this in the next minor release of Slim 3 and note that group() is deprecated and will be removed in the next major version.
I can see cases where this _could_ be more confusing. I commonly have a selection of routes which have no route pattern prefix, but share middleware so I put them in a group. By name, it sounds less natural to add middleware to a prefix, especially when there might not be a route pattern prefix.
The word group seems to cover both use cases better than prefix does. If I was writing the docs, this doesn't read as well:
If you have multiple routes which share middleware, consider putting them in a
prefixwith an empty route pattern. You can thenaddthe middleware to the entire prefix.
I'm not saying I oppose this, just thinking it through...
I don't necessarily disagree. The disconnect that we have a the moment is that a group isn't a thing and it sounds like it is at the moment.
I too dislike the term "group"... I kinda liked the verbage of, $app->mount('')
I agree with @tflight. The group term is also used for set a middleware to a group of routes.
@silentworks i imagine a method "addMiddleware" to the prefix, but it sound very 'hacky'.
$app = new \Slim\App();
$app->prefix('', function () {
$this->get('/', function ($request, $response, $args) {});
$this->get('/posts', function ($request, $response, $args) {});
})->addMiddelware(function(){});
@damianopetrungaro that is true, we need a better name than prefix I guess.
IMHO group is a good name, it specifies the real intent.
We may discuss on an implementation like this:
$app = new \Slim\App();
$app->group(function () {
$this->get('/', function ($request, $response, $args) {});
$this->get('/posts', function ($request, $response, $args) {});
})->prefix('prefix-here')->addMiddelware(function(){});
It's just an idea for split the two concepts and have a easy way for maintains it.
@silentworks what do you think about it?
Anyway i like the "group" concept that is implemented at the moment.
It's easy to use and do its job 馃槃
I like that idea, or maybe we should do as you said and leave it as it is. We would just need to make it very clear in documentation that group is not the same as a get, post ....
Perhaps an extension of group which take a in an array of options, such as prefix and middleware to add?
I'd write a code sample but on mobile currently. Similar to what Dan said however group could take 2 arguments instead of bolting to the end of the declaration?
I created a group with a path of '' (empty string). That's not really a prefix, but in essence is a grouping. I did this to assign scopes around my routes for chadicus/slim-oauth2-middleware
I created a group with a path of '' (empty string). That's not really a prefix, but in essence is a grouping. I did this to assign scopes around my routes for chadicus/slim-oauth2-middleware
This is one of the key use-cases of group.
Closing this issue as it seems that everyone is happy enough with group as the method name
Most helpful comment
I can see cases where this _could_ be more confusing. I commonly have a selection of routes which have no route pattern prefix, but share middleware so I put them in a group. By name, it sounds less natural to
addmiddleware to aprefix, especially when there might not be a route pattern prefix.The word
groupseems to cover both use cases better thanprefixdoes. If I was writing the docs, this doesn't read as well:I'm not saying I oppose this, just thinking it through...