I see a lot in common with the framework-extra-bundle here, which is nice, but can't we do some extra miles and replace the runtime logic inControllerListener by a compile-time one?

This would require using a tag to identify controllers. We could reusecontroller.service_arguments or add a newkernel.controller (that could maybe replacecontroller.service_arguments btw)

WDYT?

Let me see if I understand. What you're proposing is a way to fetch data from a compiled container instead of a dedicatedArgumentValueResolver and the value would be resolved byServiceValueResolver or something like that.

Yes, something like that :)

I would recommend a different tag name, I'm not using service arguments for my controllers, and I'd still like to use this feature 😄

Hi@nicolas-grekas, I've thought a lot how could we leverage the compilation mechanism to go ahead with this feature. One possible solution would be make the generated container implementArgumentValueResolverInterface interface and put some generated logic there. Essentially we would have:

1. Container implementingArgumentValueResolverInterface:

class appDevDebugProjectContainerextends Containerimplements ArgumentValueResolverInterface {privatestatic$argumentResolvers = ['SomeController::IndexAction:Logger' =>'resolveSomeControllerIndexActionLoggerArgument.php'    ];publicfunctionsupports($request,$argumentMetadata) {$controllerName =...;returnisset(self::$argumentResolvers[$controllerName]);   }publicfunctionresolve($request,$argumentMetadata) {$controllerName =...;yield$this->load(self::$argumentResolvers[$controllerName]);   }}

2. Dedicated file resolver to each controller argument

This file could be located inside the generated container directory.

// var/cache/prod/ContainerOOVkbxl/resolveSomeControllerIndexActionLoggerArgument.phpreturn$this->get(LoggerInterface::class);

3. Register the container in the argument value resolver list

Honestly I can't see another way to implement this feature leveraging the compilation system much different from this. If you still see a better way to go, I'm totally opened and curious to hear you. :) Otherwise, we can keep the logic in a listener and do the job there. WDYT?

Thinking about tags for controllers, what if create a compile pass to read controllers from routing config? We wouldn't need to create a new tag nor use the existing one. Actually, the existing one could be deprecated.

There's a possible link between this PR and#36320

About parsing route during compilation, that's orthogonal to the way things are designed today: routes are loadedafter the container is compiled. Not sure it's worth pursuing.

About parsing route during compilation, that's orthogonal to the way things are designed today: routes are loadedafter the container is compiled. Not sure it's worth pursuing.

Ok and agree considering the Symfony's design. My opinion about this is that the framework - in a general aspect - already knows what controllers are configured and devs wouldn't need to configure it again through tags. But this subject is not part of this PR and I don't want to discuss here to not change the main scope of this feature.

About the implementation of this feature, which way should we go?@nicolas-grekas, could you readthis and explain if this is what you thoughthere?

I see a lot in common with the framework-extra-bundle here, which is nice, but can't we do some extra miles and replace the runtime logic inControllerListener by a compile-time one?

This would require using a tag to identify controllers. We could reusecontroller.service_arguments or add a newkernel.controller (that could maybe replacecontroller.service_arguments btw)

WDYT?

I've managed with dropping the annotation controller listener and extracting it to the compiler pass. I decided to compile annotations in the service container, as they are holders of information needed to process the request, and also some validation can already occur at the compile-time.
I mainly based my compiler passRegisterControllerAnnotationLocatorsPass on theRegisterControllerArgumentLocatorsPass. For each controller class, method or argument there's a registered container with all annotations, but only if any occurs. For now, I reused thecontroller.service_argument but it'd be better to rename it to thecontroller or thekernel.controller tag for more clarity. The main struggle with this was of course the problem with exporting objects to the service container. I came up with a simple solution: use the builtin__set_state method that is used byvar_export itself, in case of absence use the builtin serialization.
In my opinion, it's sufficient for just exporting annotations - in most cases, they have a simple structure. In general, exporting objects to the service container seem to be a broader topic, that's why I created theObjectExporterInterface and put my implementation in theDefaultObjectExporter. I thought I'll be able to use theVarExporter component, but for now, I don't see it fitting. I think exporting objects can be another great feature for the DI component. Everything that I've mentioned is already implemented and partially tested (I still need to work on it) in my bundleJungiFrameworkExtraBundle.

Now regarding the PR itself - the@QueryParam annotation. I've already put some of my thoughts in#36037 (comment) (quite long, can be boring).

Regarding what@nicolas-grekas wrote in#36037 (comment)

What is likely a problem is when it just provides another way to access some info: we don't need several ways to do what is already possible, because that calls for confusion.

Maybe start with a single annotation, eg QueryParam?

IMO starting it only with the@QueryParam annotation can also lead to confusion in some cases, mostly when someone will use it in a mixed way eg. POST & GET data. Someone can think why then at all use the@QueryParam annotation if still, I need to query theRequest instance to access the needed data? I think this annotation request style is great when can be used in order to avoid querying the wholeRequest object, but when it comes down to cases where theRequest instance is still needed then it's better to rely completely on it and do not use the annotations.
I've already used this annotation request style in several of my projects and most used and helpful is without a doubt the@RequestBody annotation. I don't even think I could work without it now doing the processing of some DTOs in the request. Maybe instead of just releasing the@QueryParam it'd better start from the@RequestBody or just release them together? Or just keep it in the extra bundle and see how they are doing? :)

WDYT?

Closing as#37829 introduced a simpler way to implement such attributes.

Implementing a simple RequestQuery attribute could be something like:

diff --git a/src/Symfony/Component/HttpKernel/Attribute/RequestQuery.php b/src/Symfony/Component/HttpKernel/Attribute/RequestQuery.phpnew file mode 100644index 0000000000..133c5457ae--- /dev/null+++ b/src/Symfony/Component/HttpKernel/Attribute/RequestQuery.php@@ -0,0 +1,22 @@+<?php++/*+ * This file is part of the Symfony package.+ *+ * (c) Fabien Potencier <fabien@symfony.com>+ *+ * For the full copyright and license information, please view the LICENSE+ * file that was distributed with this source code.+ */++namespace Symfony\Component\HttpKernel\Attribute;++use Attribute;++/**+ * Gets the request query parameter of the same name as the argument name.+ */+#[Attribute(Attribute::TARGET_PARAMETER)]+class RequestQuery implements ArgumentInterface+{+}diff --git a/src/Symfony/Component/HttpKernel/Controller/ArgumentResolver.php b/src/Symfony/Component/HttpKernel/Controller/ArgumentResolver.phpindex 4285ba7631..e78e07c8c6 100644--- a/src/Symfony/Component/HttpKernel/Controller/ArgumentResolver.php+++ b/src/Symfony/Component/HttpKernel/Controller/ArgumentResolver.php@@ -14,6 +14,7 @@ namespace Symfony\Component\HttpKernel\Controller; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpKernel\Controller\ArgumentResolver\DefaultValueResolver; use Symfony\Component\HttpKernel\Controller\ArgumentResolver\RequestAttributeValueResolver;+use Symfony\Component\HttpKernel\Controller\ArgumentResolver\RequestQueryResolver; use Symfony\Component\HttpKernel\Controller\ArgumentResolver\RequestValueResolver; use Symfony\Component\HttpKernel\Controller\ArgumentResolver\SessionValueResolver; use Symfony\Component\HttpKernel\Controller\ArgumentResolver\VariadicValueResolver;@@ -89,6 +90,7 @@ final class ArgumentResolver implements ArgumentResolverInterface             new RequestAttributeValueResolver(),             new RequestValueResolver(),             new SessionValueResolver(),+            new RequestQueryResolver(),             new DefaultValueResolver(),             new VariadicValueResolver(),         ];diff --git a/src/Symfony/Component/HttpKernel/Controller/ArgumentResolver/RequestQueryResolver.php b/src/Symfony/Component/HttpKernel/Controller/ArgumentResolver/RequestQueryResolver.phpnew file mode 100644index 0000000000..f68570c40e--- /dev/null+++ b/src/Symfony/Component/HttpKernel/Controller/ArgumentResolver/RequestQueryResolver.php@@ -0,0 +1,39 @@+<?php++/*+ * This file is part of the Symfony package.+ *+ * (c) Fabien Potencier <fabien@symfony.com>+ *+ * For the full copyright and license information, please view the LICENSE+ * file that was distributed with this source code.+ */++namespace Symfony\Component\HttpKernel\Controller\ArgumentResolver;++use Symfony\Component\HttpFoundation\Request;+use Symfony\Component\HttpKernel\Attribute\RequestQuery;+use Symfony\Component\HttpKernel\Controller\ArgumentValueResolverInterface;+use Symfony\Component\HttpKernel\ControllerMetadata\ArgumentMetadata;++/**+ * @author Fabien Potencier <fabien@symfony.com>+ */+final class RequestQueryResolver implements ArgumentValueResolverInterface+{+    /**+     * {@inheritdoc}+     */+    public function supports(Request $request, ArgumentMetadata $argument): bool+    {+        return $argument->getAttribute() instanceof RequestQuery;+    }++    /**+     * {@inheritdoc}+     */+    public function resolve(Request $request, ArgumentMetadata $argument): iterable+    {+        yield $request->query->all()[$argument->getName()] ?? $argument->hasDefaultValue() ? $argument->getDefaultValue() : null;+    }+}

Let's resume the discussion in#38162