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
namespaceElao\Attribute;
useSymfony\Component\DependencyInjection\Attribute\AutoconfigureTag;
#[\Attribute(\Attribute::TARGET_CLASS)]
classDBALTypeextendsAutoconfigureTag
{
publicfunction__construct(
public ?string$name = null, // if null, use enum FQCN as namepublicstring$type = 'single',
public\BackedEnum|int|string|null$defaultOnNull = null,
)
{
parent::__construct('elao.dbal_type');
}
}
then its easy to find inside CompilerPass
publicfunctionprocess(ContainerBuilder$container)
{
// Find all services tagged with 'your_bundle.dbal_type'$taggedServices = $container->findTaggedServiceIds('elao.dbal_type');
$enums = [];
foreach ($taggedServicesas$id => $tags) {
$definition = $container->getDefinition($id);
$class = $definition->getClass();
if (class_exists($class)) {
$reflection = new \ReflectionClass($class);
if ($reflection->isEnum()) {
$enums[] = $class;
}
}
}
// Process $enums as needed$this->registerDBALTypes($enums);
}
I just think this is more flexible approach than always remembering to add a config type to yaml config.
And, as an added benefit, because of the reflection used in PHP code, this allows us to use TypedFieldMapper to map all such enums to their types. So we can then use
Sounds interesting indeed. TIL about the type field mappers, thanks 👌🏻
We have to agree what to do with the yaml config, especially if we have conflicts. Will one take precedence? Will we throw?
Usually, YAML config wins over PHP attributes. It is meant to allow overriding the config per Symfony env easily. Despite I don't see much use-case for it, I guess we should stick to the convention here.
I have a proposal: right now we require to list manually all types that we want to integrate with doctrine inside
elao_enum.yaml
file.Let's introduce a new attribute
Elao\Attribute\DBALType
.We can take advantage of autoconfiguration:
then its easy to find inside
CompilerPass
I just think this is more flexible approach than always remembering to add a config type to yaml config.
And, as an added benefit, because of the reflection used in PHP code, this allows us to use
TypedFieldMapper
to map all such enums to their types. So we can then useinstead of
WDYT?
We have to agree what to do with the yaml config, especially if we have conflicts. Will one take precedence? Will we throw?
The text was updated successfully, but these errors were encountered: