• Should HTTP method-style attributes remain Get/Post/Put/... (current), or should naming move toward an uppercase style?

I have forgotten, that it would break our code style rules - therefore I am fine having the PascalCase

@josbeir In your usage example the $routes->attributes(); in inside a scope. It should be moved out to avoid someone incorrectly thinking that the call needs to be done per scope.

@josbeir In your usage example the $routes->attributes(); in inside a scope. It should be moved out to avoid someone incorrectly thinking that the call needs to be done per scope.

Updated, but it actually works like you'd expect. If you put it in a scope then all discovered attributes from a resolver config (which is the only optional argument of attributes() would follow that scope.

So yes for root attributes it can be added inside the '/' scope or outside, they will all start at root level. The example illustrated that it also work likes that (handy feature actually 😎)

Updated, but it actually works like you'd expect. If you put it in a scope then all discovered attributes from a resolver config (which is the only optional argument of attributes() would follow that scope.

Oh, so if I do $routes->scope('/admin', function () { $routes->attributes() }); only, then any attributes I might might set like #[Scope('/articles', namePrefix: 'articles:')] will be ignored?

Oh, so if I do $routes->scope('/admin', function () { $routes->attributes() }); only, then any attributes I might might set like #[Scope('/articles', namePrefix: 'articles:')] will be ignored?

No, they just will all be connected to the /admin scope.
So if you set an a Scope attribute for articles then it will be connected to /admin scope. = /admin/articles/....

// routes.php
$routes->scope('/admin', function(RouteBuilder $routes) {
   $routes->attributes();
});

// A controller
#[Scope('/articles')]
class ArticlesController extends AppController {
   
   #[Get('/list')]
   public function index() {
   }
}

will result in /admin/articles/list

Basically the resolver holds the list of discovered route attributes. Then these routes are connected to the scope where attributes() was called in.

So if a resolver configuration is there that targets a specific path/pattern then that config could be used to connect a specific subset of routes to a scope. Not something we should explicitly promote but it is a use case that could be handy.

@markstory @dereuromark thoughts?

Minor Observations:

Copilot's point about duplicate regex - The extractPathPlaceholders() duplicating PLACEHOLDER_REGEX from the Route class is a valid concern for maintainability.

Questions I'd have:

• How does route ordering work? If multiple controllers define overlapping patterns, is it deterministic?
• What happens with conflicting class-level and method-level middleware declarations?

How does route ordering work? If multiple controllers define overlapping patterns, is it deterministic?

I believe it would be non-deterministic and whichever gets loaded first will take precedence.

What happens with conflicting class-level and method-level middleware declarations?

The docblock of AttributeRouteConnector::mergeMiddleware() says:

Merge multiple middleware lists while preserving order.

String middleware names are deduplicated by value. Closures are always appended
since they cannot be meaningfully compared for equality.

@josbeir I don't see tests using the Middleware attribute.

@josbeir I don't see tests using the Middleware attribute.

Added an integration test to confirm registration is working properly trough the resolver, it was already synthetically tested.
Side-note: I added support for registering closure based middlewares but as this is PHP 8.5+ i didn't add any integration tests as php < 8.5 can't parse these type of attributes and returns in errors. (I could conditionally generate a test file but that seems just too much maintenance work and will probably get forgotten later)

Below a little example of how this works (php 8.5+ only):

<?php
#[Scope(path: '/api')]
#[Middleware(static function (ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface {
    $response = $handler->handle($request);

    return $response->withHeader('X-Api-Version', '2.0');
})]
class ArticlesController extends AppController
{
    #[Get('/articles', 'articles:index')]
    #[Middleware(static function (ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface {
        // inline rate-limit logic
        return $handler->handle($request);
    })]
    public function index(): void
    {
    }
}

docs PR: cakephp/docs#8257

Added an integration test to confirm registration is working properly trough the resolver...

Using route scoped middewares is a 2 step process, first you need to register the middleware (RouteBuilder::registerMiddleware()) and then apply it (RouteBuilder::applyMiddleware()).

So when using the Middleware attribute with string args, you only specify the middlewares to be applied, they still have to be registered isn't?

Edit: I see now the docs clarify the above.

I added support for registering closure based middlewares but as this is PHP 8.5+ i didn't add any integration tests as php < 8.5 can't parse these type of attributes and returns in errors

Would be nice if it would be possible to load a file only for PHP 8.5+, so that we don't have an untested feature.

I added support for registering closure based middlewares but as this is PHP 8.5+ i didn't add any integration tests as php < 8.5 can't parse these type of attributes and returns in errors

Would be nice if it would be possible to load a file only for PHP 8.5+, so that we don't have an untested feature.

I'll see what I can whip up, but it is already tested, just not coming from the registry directly