发布于 2015-08-27 16:37:15 | 247 次阅读 | 评论: 0 | 来源: 网络整理
Dependency Injection Tags are little strings that can be applied to a service to “flag” it to be used in some special way. For example, if you have a service that you would like to register as a listener to one of Symfony’s core events, you can flag it with the kernel.event_listener tag.
You can learn a little bit more about “tags” by reading the “Tags” section of the Service Container chapter.
Below is information about all of the tags available inside Symfony. There may also be tags in other bundles you use that aren’t listed here.
| Tag Name | Usage |
|---|---|
| assetic.asset | Register an asset to the current asset manager |
| assetic.factory_worker | Add a factory worker |
| assetic.filter | Register a filter |
| assetic.formula_loader | Add a formula loader to the current asset manager |
| assetic.formula_resource | Adds a resource to the current asset manager |
| assetic.templating.php | Remove this service if PHP templating is disabled |
| assetic.templating.twig | Remove this service if Twig templating is disabled |
| console.command | Add a command |
| data_collector | Create a class that collects custom data for the profiler |
| doctrine.event_listener | Add a Doctrine event listener |
| doctrine.event_subscriber | Add a Doctrine event subscriber |
| form.type | Create a custom form field type |
| form.type_extension | Create a custom “form extension” |
| form.type_guesser | Add your own logic for “form type guessing” |
| kernel.cache_clearer | Register your service to be called during the cache clearing process |
| kernel.cache_warmer | Register your service to be called during the cache warming process |
| kernel.event_listener | Listen to different events/hooks in Symfony |
| kernel.event_subscriber | To subscribe to a set of different events/hooks in Symfony |
| kernel.fragment_renderer | Add new HTTP content rendering strategies |
| monolog.logger | Logging with a custom logging channel |
| monolog.processor | Add a custom processor for logging |
| routing.loader | Register a custom service that loads routes |
| routing.expression_language_provider | Register a provider for expression language functions in routing |
| security.expression_language_provider | Register a provider for expression language functions in security |
| security.voter | Add a custom voter to Symfony’s authorization logic |
| security.remember_me_aware | To allow remember me authentication |
| serializer.encoder | Register a new encoder in the serializer service |
| serializer.normalizer | Register a new normalizer in the serializer service |
| swiftmailer.default.plugin | Register a custom SwiftMailer Plugin |
| templating.helper | Make your service available in PHP templates |
| translation.loader | Register a custom service that loads translations |
| translation.extractor | Register a custom service that extracts translation messages from a file |
| translation.dumper | Register a custom service that dumps translation messages |
| twig.extension | Register a custom Twig Extension |
| twig.loader | Register a custom service that loads Twig templates |
| validator.constraint_validator | Create your own custom validation constraint |
| validator.initializer | Register a service that initializes objects before validation |
Purpose: Register an asset with the current asset manager
Purpose: Add a factory worker
A Factory worker is a class implementing AsseticFactoryWorkerWorkerInterface. Its process($asset) method is called for each asset after asset creation. You can modify an asset or even return a new one.
In order to add a new worker, first create a class:
use AsseticAssetAssetInterface;
use AsseticFactoryWorkerWorkerInterface;
class MyWorker implements WorkerInterface
{
public function process(AssetInterface $asset)
{
// ... change $asset or return a new one
}
}
And then register it as a tagged service:
services:
acme.my_worker:
class: MyWorker
tags:
- { name: assetic.factory_worker }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="acme.my_worker" class="MyWorker>
<tag name="assetic.factory_worker" />
</service>
</services>
</container>
$container
->register('acme.my_worker', 'MyWorker')
->addTag('assetic.factory_worker')
;
Purpose: Register a filter
AsseticBundle uses this tag to register common filters. You can also use this tag to register your own filters.
First, you need to create a filter:
use AsseticAssetAssetInterface;
use AsseticFilterFilterInterface;
class MyFilter implements FilterInterface
{
public function filterLoad(AssetInterface $asset)
{
$asset->setContent('alert("yo");' . $asset->getContent());
}
public function filterDump(AssetInterface $asset)
{
// ...
}
}
Second, define a service:
services:
acme.my_filter:
class: MyFilter
tags:
- { name: assetic.filter, alias: my_filter }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="acme.my_filter" class="MyFilter">
<tag name="assetic.filter" alias="my_filter" />
</service>
</services>
</container>
$container
->register('acme.my_filter', 'MyFilter')
->addTag('assetic.filter', array('alias' => 'my_filter'))
;
Finally, apply the filter:
{% javascripts
'@AcmeBaseBundle/Resources/public/js/global.js'
filter='my_filter'
%}
<script src="{{ asset_url }}"></script>
{% endjavascripts %}
You can also apply your filter via the assetic.filters.my_filter.apply_to config option as it’s described here: 如何将Assetic处理器运用在特定的文件类型上. In order to do that, you must define your filter service in a separate xml config file and point to this file’s path via the assetic.filters.my_filter.resource configuration key.
Purpose: Add a formula loader to the current asset manager
A Formula loader is a class implementing AsseticFactoryLoaderFormulaLoaderInterface interface. This class is responsible for loading assets from a particular kind of resources (for instance, twig template). Assetic ships loaders for PHP and Twig templates.
An alias attribute defines the name of the loader.
Purpose: Adds a resource to the current asset manager
A resource is something formulae can be loaded from. For instance, Twig templates are resources.
Purpose: Remove this service if PHP templating is disabled
The tagged service will be removed from the container if the framework.templating.engines config section does not contain php.
Purpose: Remove this service if Twig templating is disabled
The tagged service will be removed from the container if framework.templating.engines config section does not contain twig.
Purpose: Add a command to the application
For details on registering your own commands in the service container, read the cookbook article.
Purpose: Create a class that collects custom data for the profiler
For details on creating your own custom data collection, read the cookbook article: How to Create a custom Data Collector.
Purpose: Add a Doctrine event listener
For details on creating Doctrine event listeners, read the cookbook article: 如何注册Event Listener以及Subscriber.
Purpose: Add a Doctrine event subscriber
For details on creating Doctrine event subscribers, read the cookbook article: 如何注册Event Listener以及Subscriber.
Purpose: Create a custom form field type
For details on creating your own custom form type, read the cookbook article: How to Create a Custom Form Field Type.
Purpose: Create a custom “form extension”
Form type extensions are a way for you took “hook into” the creation of any field in your form. For example, the addition of the CSRF token is done via a form type extension (FormTypeCsrfExtension).
A form type extension can modify any part of any field in your form. To create a form type extension, first create a class that implements the FormTypeExtensionInterface interface. For simplicity, you’ll often extend an AbstractTypeExtension class instead of the interface directly:
// src/Acme/MainBundle/Form/Type/MyFormTypeExtension.php
namespace AcmeMainBundleFormType;
use SymfonyComponentFormAbstractTypeExtension;
class MyFormTypeExtension extends AbstractTypeExtension
{
// ... fill in whatever methods you want to override
// like buildForm(), buildView(), finishView(), configureOptions()
}
In order for Symfony to know about your form extension and use it, give it the form.type_extension tag:
services:
main.form.type.my_form_type_extension:
class: AcmeMainBundleFormTypeMyFormTypeExtension
tags:
- { name: form.type_extension, alias: field }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="main.form.type.my_form_type_extension"
class="AcmeMainBundleFormTypeMyFormTypeExtension">
<tag name="form.type_extension" alias="field" />
</service>
</services>
</container>
$container
->register('main.form.type.my_form_type_extension', 'AcmeMainBundleFormTypeMyFormTypeExtension')
->addTag('form.type_extension', array('alias' => 'field'))
;
The alias key of the tag is the type of field that this extension should be applied to. For example, to apply the extension to any form/field, use the “form” value.
Purpose: Add your own logic for “form type guessing”
This tag allows you to add your own logic to the Form Guessing process. By default, form guessing is done by “guessers” based on the validation metadata and Doctrine metadata (if you’re using Doctrine) or Propel metadata (if you’re using Propel).
参见
For information on how to create your own type guesser, see Creating a custom Type Guesser.
Purpose: Register your service to be called during the cache clearing process
Cache clearing occurs whenever you call cache:clear command. If your bundle caches files, you should add custom cache clearer for clearing those files during the cache clearing process.
In order to register your custom cache clearer, first you must create a service class:
// src/Acme/MainBundle/Cache/MyClearer.php
namespace AcmeMainBundleCache;
use SymfonyComponentHttpKernelCacheClearerCacheClearerInterface;
class MyClearer implements CacheClearerInterface
{
public function clear($cacheDir)
{
// clear your cache
}
}
Then register this class and tag it with kernel.cache_clearer:
services:
my_cache_clearer:
class: AcmeMainBundleCacheMyClearer
tags:
- { name: kernel.cache_clearer }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="my_cache_clearer" class="AcmeMainBundleCacheMyClearer">
<tag name="kernel.cache_clearer" />
</service>
</services>
</container>
$container
->register('my_cache_clearer', 'AcmeMainBundleCacheMyClearer')
->addTag('kernel.cache_clearer')
;
Purpose: Register your service to be called during the cache warming process
Cache warming occurs whenever you run the cache:warmup or cache:clear task (unless you pass --no-warmup to cache:clear). It is also run when handling the request, if it wasn’t done by one of the commands yet. The purpose is to initialize any cache that will be needed by the application and prevent the first user from any significant “cache hit” where the cache is generated dynamically.
To register your own cache warmer, first create a service that implements the CacheWarmerInterface interface:
// src/Acme/MainBundle/Cache/MyCustomWarmer.php
namespace AcmeMainBundleCache;
use SymfonyComponentHttpKernelCacheWarmerCacheWarmerInterface;
class MyCustomWarmer implements CacheWarmerInterface
{
public function warmUp($cacheDir)
{
// ... do some sort of operations to "warm" your cache
}
public function isOptional()
{
return true;
}
}
The isOptional method should return true if it’s possible to use the application without calling this cache warmer. In Symfony, optional warmers are always executed by default (you can change this by using the --no-optional-warmers option when executing the command).
To register your warmer with Symfony, give it the kernel.cache_warmer tag:
services:
main.warmer.my_custom_warmer:
class: AcmeMainBundleCacheMyCustomWarmer
tags:
- { name: kernel.cache_warmer, priority: 0 }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="main.warmer.my_custom_warmer" class="AcmeMainBundleCacheMyCustomWarmer">
<tag name="kernel.cache_warmer" priority="0" />
</service>
</services>
</container>
$container
->register('main.warmer.my_custom_warmer', 'AcmeMainBundleCacheMyCustomWarmer')
->addTag('kernel.cache_warmer', array('priority' => 0))
;
注解
The priority value is optional, and defaults to 0. The higher the priority, the sooner it gets executed.
| Cache Warmer Class Name | Priority |
|---|---|
TemplatePathsCacheWarmer |
20 |
RouterCacheWarmer |
0 |
TemplateCacheCacheWarmer |
0 |
Purpose: To listen to different events/hooks in Symfony
This tag allows you to hook your own classes into Symfony’s process at different points.
For a full example of this listener, read the How to Create an Event Listener cookbook entry.
When adding your own listeners, it might be useful to know about the other core Symfony listeners and their priorities.
注解
All listeners listed here may not be listening depending on your environment, settings and bundles. Additionally, third-party bundles will bring in additional listeners not listed here.
| Listener Class Name | Priority |
|---|---|
ProfilerListener |
1024 |
TestSessionListener |
192 |
SessionListener |
128 |
RouterListener |
32 |
LocaleListener |
16 |
Firewall |
8 |
| Listener Class Name | Priority |
|---|---|
RequestDataCollector |
0 |
| Listener Class Name | Priority |
|---|---|
EsiListener |
0 |
ResponseListener |
0 |
ResponseListener |
0 |
ProfilerListener |
-100 |
TestSessionListener |
-128 |
WebDebugToolbarListener |
-128 |
StreamedResponseListener |
-1024 |
| Listener Class Name | Priority |
|---|---|
ProfilerListener |
0 |
ExceptionListener |
-128 |
| Listener Class Name | Priority |
|---|---|
| EmailSenderListener | 0 |
Purpose: To subscribe to a set of different events/hooks in Symfony
To enable a custom subscriber, add it as a regular service in one of your configuration, and tag it with kernel.event_subscriber:
services:
kernel.subscriber.your_subscriber_name:
class: FullyQualifiedSubscriberClassName
tags:
- { name: kernel.event_subscriber }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="kernel.subscriber.your_subscriber_name"
class="FullyQualifiedSubscriberClassName">
<tag name="kernel.event_subscriber" />
</service>
</services>
</container>
$container
->register('kernel.subscriber.your_subscriber_name', 'FullyQualifiedSubscriberClassName')
->addTag('kernel.event_subscriber')
;
注解
Your service must implement the EventSubscriberInterface interface.
注解
If your service is created by a factory, you MUST correctly set the class parameter for this tag to work correctly.
Purpose: Add a new HTTP content rendering strategy
To add a new rendering strategy - in addition to the core strategies like EsiFragmentRenderer - create a class that implements FragmentRendererInterface, register it as a service, then tag it with kernel.fragment_renderer.
Purpose: To use a custom logging channel with Monolog
Monolog allows you to share its handlers between several logging channels. The logger service uses the channel app but you can change the channel when injecting the logger in a service.
services:
my_service:
class: FullyQualifiedLoaderClassName
arguments: ["@logger"]
tags:
- { name: monolog.logger, channel: acme }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="my_service" class="FullyQualifiedLoaderClassName">
<argument type="service" id="logger" />
<tag name="monolog.logger" channel="acme" />
</service>
</services>
</container>
$definition = new Definition('FullyQualifiedLoaderClassName', array(new Reference('logger'));
$definition->addTag('monolog.logger', array('channel' => 'acme'));
$container->setDefinition('my_service', $definition);
小技巧
If you use MonologBundle 2.4 or higher, you can configure custom channels in the configuration and retrieve the corresponding logger service from the service container directly (see Configure Additional Channels without Tagged Services).
Purpose: Add a custom processor for logging
Monolog allows you to add processors in the logger or in the handlers to add extra data in the records. A processor receives the record as an argument and must return it after adding some extra data in the extra attribute of the record.
The built-in IntrospectionProcessor can be used to add the file, the line, the class and the method where the logger was triggered.
You can add a processor globally:
services:
my_service:
class: MonologProcessorIntrospectionProcessor
tags:
- { name: monolog.processor }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="my_service" class="MonologProcessorIntrospectionProcessor">
<tag name="monolog.processor" />
</service>
</services>
</container>
$container
->register('my_service', 'MonologProcessorIntrospectionProcessor')
->addTag('monolog.processor')
;
小技巧
If your service is not a callable (using __invoke) you can add the method attribute in the tag to use a specific method.
You can add also a processor for a specific handler by using the handler attribute:
services:
my_service:
class: MonologProcessorIntrospectionProcessor
tags:
- { name: monolog.processor, handler: firephp }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="my_service" class="MonologProcessorIntrospectionProcessor">
<tag name="monolog.processor" handler="firephp" />
</service>
</services>
</container>
$container
->register('my_service', 'MonologProcessorIntrospectionProcessor')
->addTag('monolog.processor', array('handler' => 'firephp'))
;
You can also add a processor for a specific logging channel by using the channel attribute. This will register the processor only for the security logging channel used in the Security component:
services:
my_service:
class: MonologProcessorIntrospectionProcessor
tags:
- { name: monolog.processor, channel: security }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="my_service" class="MonologProcessorIntrospectionProcessor">
<tag name="monolog.processor" channel="security" />
</service>
</services>
</container>
$container
->register('my_service', 'MonologProcessorIntrospectionProcessor')
->addTag('monolog.processor', array('channel' => 'security'))
;
注解
You cannot use both the handler and channel attributes for the same tag as handlers are shared between all channels.
Purpose: Register a custom service that loads routes
To enable a custom routing loader, add it as a regular service in one of your configuration, and tag it with routing.loader:
services:
routing.loader.your_loader_name:
class: FullyQualifiedLoaderClassName
tags:
- { name: routing.loader }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="routing.loader.your_loader_name"
class="FullyQualifiedLoaderClassName">
<tag name="routing.loader" />
</service>
</services>
</container>
$container
->register('routing.loader.your_loader_name', 'FullyQualifiedLoaderClassName')
->addTag('routing.loader')
;
For more information, see How to Create a custom Route Loader.
2.6 新版功能: The routing.expression_language_provider tag was introduced in Symfony 2.6.
Purpose: Register a provider for expression language functions in routing
This tag is used to automatically register expression function providers for the routing expression component. Using these providers, you can add custom functions to the routing expression language.
2.6 新版功能: The security.expression_language_provider tag was introduced in Symfony 2.6.
Purpose: Register a provider for expression language functions in security
This tag is used to automatically register expression function providers for the security expression component. Using these providers, you can add custom functions to the security expression language.
Purpose: To allow remember me authentication
This tag is used internally to allow remember-me authentication to work. If you have a custom authentication method where a user can be remember-me authenticated, then you may need to use this tag.
If your custom authentication factory extends AbstractFactory and your custom authentication listener extends AbstractAuthenticationListener, then your custom authentication listener will automatically have this tagged applied and it will function automatically.
Purpose: To add a custom voter to Symfony’s authorization logic
When you call isGranted on Symfony’s authorization checker, a system of “voters” is used behind the scenes to determine if the user should have access. The security.voter tag allows you to add your own custom voter to that system.
For more information, read the cookbook article: How to Implement your own Voter to Blacklist IP Addresses.
Purpose: Register a new encoder in the serializer service
The class that’s tagged should implement the EncoderInterface and DecoderInterface.
For more details, see How to Use the Serializer.
Purpose: Register a new normalizer in the Serializer service
The class that’s tagged should implement the NormalizerInterface and DenormalizerInterface.
For more details, see How to Use the Serializer.
Purpose: Register a custom SwiftMailer Plugin
If you’re using a custom SwiftMailer plugin (or want to create one), you can register it with SwiftMailer by creating a service for your plugin and tagging it with swiftmailer.default.plugin (it has no options).
注解
default in this tag is the name of the mailer. If you have multiple mailers configured or have changed the default mailer name for some reason, you should change it to the name of your mailer in order to use this tag.
A SwiftMailer plugin must implement the Swift_Events_EventListener interface. For more information on plugins, see SwiftMailer’s Plugin Documentation.
Several SwiftMailer plugins are core to Symfony and can be activated via different configuration. For details, see SwiftmailerBundle Configuration (“swiftmailer”).
Purpose: Make your service available in PHP templates
To enable a custom template helper, add it as a regular service in one of your configuration, tag it with templating.helper and define an alias attribute (the helper will be accessible via this alias in the templates):
services:
templating.helper.your_helper_name:
class: FullyQualifiedHelperClassName
tags:
- { name: templating.helper, alias: alias_name }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="templating.helper.your_helper_name"
class="FullyQualifiedHelperClassName">
<tag name="templating.helper" alias="alias_name" />
</service>
</services>
</container>
$container
->register('templating.helper.your_helper_name', 'FullyQualifiedHelperClassName')
->addTag('templating.helper', array('alias' => 'alias_name'))
;
Purpose: To register a custom service that loads translations
By default, translations are loaded from the filesystem in a variety of different formats (YAML, XLIFF, PHP, etc).
参见
Learn how to load custom formats in the components section.
Now, register your loader as a service and tag it with translation.loader:
services:
main.translation.my_custom_loader:
class: AcmeMainBundleTranslationMyCustomLoader
tags:
- { name: translation.loader, alias: bin }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="main.translation.my_custom_loader"
class="AcmeMainBundleTranslationMyCustomLoader">
<tag name="translation.loader" alias="bin" />
</service>
</services>
</container>
$container
->register('main.translation.my_custom_loader', 'AcmeMainBundleTranslationMyCustomLoader')
->addTag('translation.loader', array('alias' => 'bin'))
;
The alias option is required and very important: it defines the file “suffix” that will be used for the resource files that use this loader. For example, suppose you have some custom bin format that you need to load. If you have a bin file that contains French translations for the messages domain, then you might have a file app/Resources/translations/messages.fr.bin.
When Symfony tries to load the bin file, it passes the path to your custom loader as the $resource argument. You can then perform any logic you need on that file in order to load your translations.
If you’re loading translations from a database, you’ll still need a resource file, but it might either be blank or contain a little bit of information about loading those resources from the database. The file is key to trigger the load method on your custom loader.
Purpose: To register a custom service that extracts messages from a file
When executing the translation:update command, it uses extractors to extract translation messages from a file. By default, the Symfony framework has a TwigExtractor and a PhpExtractor, which help to find and extract translation keys from Twig templates and PHP files.
You can create your own extractor by creating a class that implements ExtractorInterface and tagging the service with translation.extractor. The tag has one required option: alias, which defines the name of the extractor:
// src/Acme/DemoBundle/Translation/FooExtractor.php
namespace AcmeDemoBundleTranslation;
use SymfonyComponentTranslationExtractorExtractorInterface;
use SymfonyComponentTranslationMessageCatalogue;
class FooExtractor implements ExtractorInterface
{
protected $prefix;
/**
* Extracts translation messages from a template directory to the catalogue.
*/
public function extract($directory, MessageCatalogue $catalogue)
{
// ...
}
/**
* Sets the prefix that should be used for new found messages.
*/
public function setPrefix($prefix)
{
$this->prefix = $prefix;
}
}
services:
acme_demo.translation.extractor.foo:
class: AcmeDemoBundleTranslationFooExtractor
tags:
- { name: translation.extractor, alias: foo }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="acme_demo.translation.extractor.foo"
class="AcmeDemoBundleTranslationFooExtractor">
<tag name="translation.extractor" alias="foo" />
</service>
</services>
</container>
$container->register(
'acme_demo.translation.extractor.foo',
'AcmeDemoBundleTranslationFooExtractor'
)
->addTag('translation.extractor', array('alias' => 'foo'));
Purpose: To register a custom service that dumps messages to a file
After an Extractor has extracted all messages from the templates, the dumpers are executed to dump the messages to a translation file in a specific format.
Symfony already comes with many dumpers:
CsvFileDumperIcuResFileDumperIniFileDumperMoFileDumperPoFileDumperQtFileDumperXliffFileDumperYamlFileDumperYou can create your own dumper by extending FileDumper or implementing DumperInterface and tagging the service with translation.dumper. The tag has one option: alias This is the name that’s used to determine which dumper should be used.
services:
acme_demo.translation.dumper.json:
class: AcmeDemoBundleTranslationJsonFileDumper
tags:
- { name: translation.dumper, alias: json }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="acme_demo.translation.dumper.json"
class="AcmeDemoBundleTranslationJsonFileDumper">
<tag name="translation.dumper" alias="json" />
</service>
</services>
</container>
$container->register(
'acme_demo.translation.dumper.json',
'AcmeDemoBundleTranslationJsonFileDumper'
)
->addTag('translation.dumper', array('alias' => 'json'));
参见
Learn how to dump to custom formats in the components section.
Purpose: To register a custom Twig Extension
To enable a Twig extension, add it as a regular service in one of your configuration, and tag it with twig.extension:
services:
twig.extension.your_extension_name:
class: FullyQualifiedExtensionClassName
tags:
- { name: twig.extension }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="twig.extension.your_extension_name"
class="FullyQualifiedExtensionClassName">
<tag name="twig.extension" />
</service>
</services>
</container>
$container
->register('twig.extension.your_extension_name', 'FullyQualifiedExtensionClassName')
->addTag('twig.extension')
;
For information on how to create the actual Twig Extension class, see Twig’s documentation on the topic or read the cookbook article: How to Write a custom Twig Extension.
Before writing your own extensions, have a look at the Twig official extension repository which already includes several useful extensions. For example Intl and its localizeddate filter that formats a date according to user’s locale. These official Twig extensions also have to be added as regular services:
services:
twig.extension.intl:
class: Twig_Extensions_Extension_Intl
tags:
- { name: twig.extension }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="twig.extension.intl" class="Twig_Extensions_Extension_Intl">
<tag name="twig.extension" />
</service>
</services>
</container>
$container
->register('twig.extension.intl', 'Twig_Extensions_Extension_Intl')
->addTag('twig.extension')
;
Purpose: Register a custom service that loads Twig templates
By default, Symfony uses only one Twig Loader - FilesystemLoader. If you need to load Twig templates from another resource, you can create a service for the new loader and tag it with twig.loader:
services:
acme.demo_bundle.loader.some_twig_loader:
class: AcmeDemoBundleLoaderSomeTwigLoader
tags:
- { name: twig.loader, priority: 0 }
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service
id="acme.demo_bundle.loader.some_twig_loader"
class="AcmeDemoBundleLoaderSomeTwigLoader">
<tag name="twig.loader" priority="0" />
</service>
</services>
</container>
$container
->register('acme.demo_bundle.loader.some_twig_loader', 'AcmeDemoBundleLoaderSomeTwigLoader')
->addTag('twig.loader', array('priority' => 0))
;
注解
The priority value is optional and defaults to 0. The higher priority loaders are tried first.
Purpose: Create your own custom validation constraint
This tag allows you to create and register your own custom validation constraint. For more information, read the cookbook article: How to Create a custom Validation Constraint.
Purpose: Register a service that initializes objects before validation
This tag provides a very uncommon piece of functionality that allows you to perform some sort of action on an object right before it’s validated. For example, it’s used by Doctrine to query for all of the lazily-loaded data on an object before it’s validated. Without this, some data on a Doctrine entity would appear to be “missing” when validated, even though this is not really the case.
If you do need to use this tag, just make a new class that implements the ObjectInitializerInterface interface. Then, tag it with the validator.initializer tag (it has no options).
For an example, see the EntityInitializer class inside the Doctrine Bridge.