Skip to content

#192 - Define the controllers and the HTTP value resolver explicitly, without autowiring nor autoconfiguration - #193

Merged
njoubert-cleverage merged 1 commit into
mainfrom
192
Oct 21, 2026
Merged

njoubert-cleverage merged 1 commit into
mainfrom
192

Conversation

@njoubert-cleverage

Copy link
Copy Markdown
Member

Description

Fixes #192, as cleverage/process-bundle#149 (PR cleverage/process-bundle#291).

  • config/services/controller.yaml: the 10 controllers are defined one by one instead of a resource with autowire / autoconfigure / bind: named constructor arguments, setContainer() call with the service locator of AbstractController (@Psr\Container\ContainerInterface, replaced by the container.service_subscriber locator), and the tags autoconfiguration added: controller.service_arguments, container.service_subscriber, ea.dashboard_controller / ea.crud_controller (EasyAdmin interfaces), ea.admin_route_controller (#[AdminRoute]), routing.controller (#[Route], used by Symfony 7.3 or later, ignored before).
  • Action arguments: controller.service_arguments without attribute still autowires the arguments of the actions (Symfony behaviour, independent of autowire), so the EasyAdmin actions are unchanged. LoginController::__invoke() gets AuthenticationUtils from the tag (action / argument / id), LaunchAction::__invoke() its $uploadDirectory from a bind of its own definition.
  • config/services/http_value_resolver.yaml: the controller.targeted_value_resolver (http_process_execution) and controller.argument_value_resolver tags, instead of autoconfigure.
  • CHANGELOG.

Compiled container of the test kernel (debug XML dump, Symfony 8.1, EasyAdmin 5.7), before / after, compared for the controllers and the value resolver: same classes, arguments, tags and setContainer() locator; only change in the action arguments locators: the $context binding of the former resource registered the AdminContextFactory service for the AdminContext $context arguments of the EasyAdmin actions (index(), detail(), edit()…). It was never used (EasyAdmin's AdminContextResolver, priority 0, resolves the context before the ServiceValueResolver, priority -50), and it is gone: these arguments are now resolved as in any EasyAdmin application.

Checked in process-bundle-demo (patch applied to the vendor), with the same results as main: lint:container OK; login, dashboard, process list, launch form (demo.upload_and_run), index of the 4 CRUD pages, HTTP API without token (401).

Tests: no service of the bundle is autowired or autoconfigured, every class of src/Controller/ is registered as a public controller with the AbstractController services, tags of the targeted value resolver. With coverage (pcov): 455 tests, no risky test. Also run with --prefer-lowest (Symfony 6.4). PHPStan, PHP-CS-Fixer, Rector and Twig-CS-Fixer OK.

Requirements

  • Documentation updates
    • Reference
    • Cookbooks
    • Changelog
  • Unit tests

Breaking changes

None: same services, arguments and tags (the controllers are @internal). A new controller must now be declared in controller.yaml (checked by the tests).

🤖 Generated with Claude Code

… without autowiring nor autoconfiguration

The controllers were loaded by a resource with autowire and autoconfigure,
the HTTP value resolver relied on autoconfigure. They are defined explicitly
(Symfony best practices for bundles), with the same compiled arguments, tags
and calls. The $context binding no longer registers AdminContextFactory for
the AdminContext arguments of the EasyAdmin actions. Tests and CHANGELOG.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@njoubert-cleverage
njoubert-cleverage merged commit 3726194 into main Oct 21, 2026
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Define the controllers and the HTTP value resolver explicitly, without autowiring nor autoconfiguration

1 participant