You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 DocumentManager instance. This makes it impossible to create more complex filters that might rely on other objects to do their work
Due to FilterCollection instantiating 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 addFilterCriteria should not only receive a ClassMetadata instance but also the document manager in use. This allows reusing a filter instance for multiple document managers
The addFilter method in Configuration needs to be extended to allow adding a filter instance to the configuration instead of just its class name. FilterCollection must 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.
The text was updated successfully, but these errors were encountered:
Feature Request
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 theFilterCollection
according to the configuration. There are several issues with this approach:DocumentManager
instance. This makes it impossible to create more complex filters that might rely on other objects to do their workFilterCollection
instantiating 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:
addFilterCriteria
should not only receive aClassMetadata
instance but also the document manager in use. This allows reusing a filter instance for multiple document managersaddFilter
method inConfiguration
needs to be extended to allow adding a filter instance to the configuration instead of just its class name.FilterCollection
must 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.
The text was updated successfully, but these errors were encountered: