This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle] Add new "controller.service_arguments" tag to inject services into actions
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | (no test yet)
| Fixed tickets | -
| License | MIT
| Doc PR | -
Talking with @simensen and @weaverryan, we wondered if we could leverage the `ArgumentResolver` mechanism to make it inject services on demand, using e.g. autowiring.
```php
class PostController
{
public function indexAction(Request $request, PostRepository $postRepository)
{
// PostRepository comes from the container
$postRepository->findAll(); // ...
}
}
```
This PR achieves that, using a new "controller.service_arguments" tag. Typically:
```yaml
services:
AppBundle\Controller\PostController:
autowire: true
tags:
- name: controller.service_arguments
```
It also supports with explicit wiring (thus doesn't necessarily require autowiring if you don't want to use it):
```yaml
services:
AppBundle\Controller\PostController:
tags:
- name: controller.service_arguments
action: fooAction
argument: logger
id: my_logger
```
~~The attached diff is bigger than strictly required for now, until #21770 is merged.~~
Todo:
- [x] rebase on top of #21770 when merged
- [x] add tests
- [x] add cleaning pass to remove empty service locators
Commits
-------
9c6e672780 [FrameworkBundle] Add new "controller.service_arguments" tag to inject services into actions
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Form][FrameworkBundle] Move FormPass to the Form component
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
So that anyone using only Form and DI can use it for registering form types/type guessers.
Follows #19443, related to #21284
Commits
-------
e68a6d963c [FrameworkBundle][Form] Move FormPass to the Form component
This PR was merged into the 3.2-dev branch.
Discussion
----------
[FrameworkBundle] removed the Security Core and Security CSRF component dependencies on FrameworkBundle
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/security-core and symfony/security-csrf explicitly)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15748 partially
| License | MIT
| Doc PR | n/a
Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Security Core and CSRF components from the list.
Commits
-------
d703784 [FrameworkBundle] removed the Security Core and Security CSRF component dependencies on FrameworkBundle
This PR was merged into the 3.2-dev branch.
Discussion
----------
[FrameworkBundle] removed the Templating component dependency on FrameworkBundle
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/templating explicitly)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15748 partially
| License | MIT
| Doc PR | n/a
Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Templating component from the list.
I made most of the work in previous version, so this change is really just about adding a good error message when templating is not enabled. For the record, this is also in the path of making possible to use Symfony with Twig without using the Templating component indirection (I think that this is in fact the last step).
Commits
-------
b3de62f [FrameworkBundle] removed the Templating component dependency on FrameworkBundle
