-
-
Notifications
You must be signed in to change notification settings - Fork 513
Open
Labels
Description
Feature Request
| Q | A |
|---|---|
| New Feature | yes |
| RFC | yes |
| BC Break | not yet |
Summary
The Configuration::addFilter method currently only allows adding a filter by specifying its name, class and optional parameters. When needed, those filters are instantiated by the FilterCollection according to the configuration. There are several issues with this approach:
- The base class for filters specifies a final constructor that takes a
DocumentManagerinstance. This makes it impossible to create more complex filters that might rely on other objects to do their work - Due to
FilterCollectioninstantiating the filters itself, they cannot be configured as services in the Symfony Bundle (see Dependency Injection and ODM Filter DoctrineMongoDBBundle#547). Similar to that, using dependency injection to inject other services is impossible due to the constructor as mentioned above.
To alleviate these pains, the filter handling should be changed completely to allow more flexibility:
- Instead of providing an abstract class with a final constructor, we should provide an interface that must be implemented by each filter
- The
addFilterCriteriashould not only receive aClassMetadatainstance but also the document manager in use. This allows reusing a filter instance for multiple document managers - The
addFiltermethod inConfigurationneeds to be extended to allow adding a filter instance to the configuration instead of just its class name.FilterCollectionmust be added accordingly.
The old way of adding filters should be deprecated and dropped in 3.0. Until then, both ways of adding filters will be supported.