kassko / class-resolver-bundle
Integrate the class-resolver component to Symfony
Installs: 20 902
Dependents: 1
Suggesters: 0
Security: 0
Stars: 0
Watchers: 2
Forks: 0
Open Issues: 0
Requires
- php: >=5.5.0
- kassko/class-resolver: ^1.0
- symfony/framework-bundle: ^2.5|^3.0|^4.0|^5.0
Requires (Dev)
- phpunit/phpunit: ~4.4
- dev-master
- 1.0.x-dev
- v1.0.3
- v1.0.2
- v1.0.1
- v1.0.0
- v0.3.3.1
- v0.3.3.0
- v0.3.2.0
- v0.3.1.0
- v0.3.0.1-alpha
- v0.3.0.0-alpha
- 0.2.0-alpha.8
- 0.2.0-alpha.7
- 0.2.0-alpha.6
- 0.2.0-alpha.5
- 0.2.0-alpha.4
- 0.2.0-alpha.3
- 0.2.0-alpha.2
- 0.1.2-alpha
- 0.1.1-alpha
- 0.1.0-alpha
- dev-kassko-compat-sf4and5
- dev-kassko-try
- dev-kassko-new_resolvers
This package is not auto-updated.
Last update: 2024-11-21 08:01:52 UTC
README
Bundle which integrates class-resolver
into Symfony. Please for natives features, take a look at the class-resolver documentation
.
Installation
You can install this component with composer
composer require kassko/class-resolver-bundle:some_version
You also need to register the bundle to your kernel:
public function registerBundles() { $bundles = array( new Kassko\Bundle\ClassResolverBundle\KasskoClassResolverBundle(), ); }
There are two differents ways to use the class-resolver
Example of semantic configuration
kassko_class_resolver: container_adapter_class: Kassko\Bundle\ClassResolverBundle\Adapter\Container\SymfonyContainerAdapter # default resolver_aliases: alias_one: my_container_resolver_service_one # - {alias_one: my_container_resolver_service_one} resolvers: container: [my_container_resolver_service_one, my_container_resolver_service_two] # or # - { resolver_service: my_container_resolver_service_one, resolver_aliases: [alias_two] } # - { resolver_service: my_container_resolver_service_two } map: map_one: resolver_service: my_map_resolver_service_one items: "My\\Namespace": my_service_one "My\\Namespace\\Two": my_service_two # or # - { class: "My\\Namespace", service: my_service_one } # - { class: "My\\Namespace\\Two", service: my_service_two } factory_adapter: - resolver_service: my_factory_adapter_resolver_service_one adapted_service: my_adapted_service_one support_method: supports resolve_method: resolve - resolver_service: my_factory_adapter_resolver_service_two adapted_service: my_adapted_service_two support_method: supports resolve_method: resolve # or with the following syntax - {resolver_service: adapter_one, adapted_factory: resolver_one} # etc static_factory_adapter: - resolver_service: my_static_factory_adapter_resolver_service_one adapted_class: my_static_resolver_class support_method: supports resolve_method: resolve - resolver_service: my_static_factory_adapter_resolver_service_two adapted_class: my_static_resolver_class support_method: supports resolve_method: resolve # or with the following syntax - {resolver_service: adapter_two, adapted_factory: resolver_two} # etc
You can define some class resolvers in semantic configuration and use them in you service configuration file
<service id="some_service_a" class="stdClass"> <argument id="my_map_resolver_service_one" type="service" /> </service> <service id="some_service_b" class="stdClass"> <argument id="my_factory_adapter_resolver_service" type="service" /> </service> <service id="some_service_c" class="stdClass"> <argument id="my_static_factory_adapter_resolver_service" type="service" /> </service>
You can both define some class resolvers on the fly and feed them with pairs [class, service] all from your service configuration file
You register your service like pairs [class, service] to a resolver you create on the fly:
<service id="some_service_a" class="stdClass"> <argument id="my_container_resolver_service_one" type="service" /> <!-- create a resolver on the fly identified by its group --> <tag name kassko_class_resolver.add group="a_group_name_choosen_by_you"> </service> <service id="some_service_b" class="stdClass"> <argument id="my_container_resolver_service_one" type="service" /> <!-- use the resolver previously created in the service `some_service_a` --> <tag name kassko_class_resolver.add group="a_group_name_choosen_by_you"> </service>
And you inject the good resolver (identified by it's group) in the concerned services:
<service id="some_service_c" class="stdClass"> <tag name kassko_class_resolver.inject group="a_group_name_choosen_by_you"> </service>
A group is a way not to manipulate some service.
This way to do has the advantage to add some new resolvers without changing the semantic configuration and to use work with only one file (the service configuration file).
For more information about this last feature, please read the more detailed documentation
Finally, you can use some class resolvers defined on the semantic configuration and feed them from your service configuration file
You register your service like a pair [class, service] in the already existing resolver my_container_resolver_service_one
:
<service id="some_service_a" class="stdClass"> <tag name kassko_class_resolver.add service="my_container_resolver_service_one"> </service>
You inject the resolver my_container_resolver_service_one
in a service which need it:
<service id="some_service_a" class="stdClass"> <argument id="my_container_resolver_service_one" type="service" /> </service>