Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Validation][FrameworkBundle] Allow EnableAutoMapping to work without auto-mapping namespaces #34707

Merged
merged 1 commit into from Dec 17, 2019
Merged

[Validation][FrameworkBundle] Allow EnableAutoMapping to work without auto-mapping namespaces #34707

merged 1 commit into from Dec 17, 2019

Conversation

ogizanagi
Copy link
Member

@ogizanagi ogizanagi commented Nov 29, 2019

Q A
Branch? 4.4
Bug fix? yes?
New feature? no
Deprecations? no
Tickets N/A
License MIT
Doc PR N/A

Currently, when no framework.validation.auto_mapping namespaces are configured, the EnableAutoMapping annotation has no effect on its own, because the loaders were removed by the fwb extension and the compiler pass.
Simply adding a namespace (even a foolish one) will make it work:

    validation:
        auto_mapping:
            '*': ~ # this does not really map anything, but allows `EnableAutoMapping` to work as loaders won't be removed.

So for those only wanting to use the auto-mapping feature by explicitly setting the EnableAutoMapping annotation, it'll be counter-intuitive, as it cannot work without declaring at least one namespace.

@@ -36,6 +36,6 @@ private function isAutoMappingEnabledForClass(ClassMetadata $metadata, string $c
}

// Fallback on the config
return null === $classValidatorRegexp || preg_match($classValidatorRegexp, $metadata->getClassName());
return null !== $classValidatorRegexp && preg_match($classValidatorRegexp, $metadata->getClassName());
Copy link
Member Author

@ogizanagi ogizanagi Nov 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ This is a BC break for the ones using the component directly:

  • before, setting $classValidatorRegexp to null would always consider the auto-mapping enabled for class by default
  • now, null will consider auto-mapping disabled for class by default, but can still be enabled by using EnableAutoMapping.

This needs a proper BC layer in any case, but I think the current way it works is not the most relevant. If you want it to be enabled by default for all classes, just use ".*". null should consider the auto-mapping feature not enabled for the class.

EDIT: see second commit

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about just doing the BC break? The trait is new to 4.4.0, let's handle this as a bug.

Copy link
Member Author

@ogizanagi ogizanagi Nov 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not about the trait actually. That's about 4.3 behavior of Doctrine/PropertyInfo loaders with a null regex. On 4.3 it was expected to enable the automapping with a null regex:

if (null !== $this->classValidatorRegexp && !preg_match($this->classValidatorRegexp, $className)) {
return false;
}

Or do you mean handle this as a bug in 4.3?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/cc @dunglas WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see also #33828

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this behavior already changed several times so... I'm in favor of introducing this change now, even if it's a real BC break (we'll have to document this in UPGRADE.md).

@@ -1312,7 +1312,7 @@ private function registerValidationConfiguration(array $config, ContainerBuilder
}

$container->setParameter('validator.auto_mapping', $config['auto_mapping']);
if (!$propertyInfoEnabled || !$config['auto_mapping'] || !class_exists(PropertyInfoLoader::class)) {
if (!$propertyInfoEnabled || !class_exists(PropertyInfoLoader::class)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we clarify in Configuration (maybe with an ->info()) the valid values for auto_mapping and what they mean?

  • Pass an array to enable auto-mapping & activate it automatically for matching namespaces
  • Pass null to turn the auto-mapping feature on only and activate with config

The wording/explanation might be more clear if we (in this PR) add a proper enable/disable flag to this config. And maybe instead of auto_mapping: ~ we make it be auto_mapping: true.

@ogizanagi
Copy link
Member Author

Alright, I've removed the BC layer and documented the BC break & alternative in CHANGELOG & UPGRADE files.

I'd suggest to:

Failure high is expected. First build is failing but does not seems related to these changes.

@@ -360,6 +360,7 @@ TwigBundle
Validator
---------

* [BC BREAK] Using null as `$classValidatorRegexp` value in `DoctrineLoader::__construct` or `PropertyInfoLoader::__construct` will not enable auto-mapping for all classes anymore, use `'{.*}'` instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{.*} or just //, but OK :)

fabpot added a commit that referenced this pull request Dec 15, 2019
…fig (ogizanagi)

This PR was merged into the 4.3 branch.

Discussion
----------

[FrameworkBundle] Add info & example to auto_mapping config

| Q             | A
| ------------- | ---
| Branch?       | 4.3 <!-- see below -->
| Bug fix?      | no
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | N/A <!-- prefix each issue number with "Fix #", if any -->
| License       | MIT
| Doc PR        | N/A

Backport part of #34707 and add example.

Commits
-------

8eb29a7 [FrameworkBundle] Add info & example to auto_mapping config
ogizanagi added a commit that referenced this pull request Dec 17, 2019
…ork without auto-mapping namespaces (ogizanagi)

This PR was squashed before being merged into the 4.4 branch (closes #34707).

Discussion
----------

[Validation][FrameworkBundle] Allow EnableAutoMapping to work without auto-mapping namespaces

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | yes?
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | N/A <!-- prefix each issue number with "Fix #", if any -->
| License       | MIT
| Doc PR        | N/A

Currently, when no `framework.validation.auto_mapping` namespaces are configured, the `EnableAutoMapping` annotation has no effect on its own, because the loaders were removed by the fwb extension and the compiler pass.
Simply adding a namespace (even a foolish one) will make it work:

```yml
    validation:
        auto_mapping:
            '*': ~ # this does not really map anything, but allows `EnableAutoMapping` to work as loaders won't be removed.
```

So for those only wanting to use the auto-mapping feature by explicitly setting the `EnableAutoMapping` annotation, it'll be counter-intuitive, as it cannot work without declaring at least one namespace.

Commits
-------

00b46fa [Validation][FrameworkBundle] Allow EnableAutoMapping to work without auto-mapping namespaces
@ogizanagi ogizanagi merged commit 00b46fa into symfony:4.4 Dec 17, 2019
@ogizanagi ogizanagi deleted the fwb_valid_automapping_dont_rm_loaders branch December 17, 2019 08:15
This was referenced Dec 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants