8000 [Form] Constraint HTML attributes guessing completely ignored · Issue #7181 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[Form] Constraint HTML attributes guessing completely ignored #7181

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.

Sign up for GitHub

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

Jump to bottom
Closed
marcospassos opened this issue Feb 25, 2013 · 5 comments
Closed

[Form] Constraint HTML attributes guessing completely ignored #7181

marcospassos opened this issue Feb 25, 2013 · 5 comments
Labels
Bug Form

Comments

@marcospassos
Copy link

Complementing #6645.

With this configuration:

    <entity name="Acme\DemoBundle\Entity\Product">
        <id name="id" column="id" type="integer">
            <generator strategy="AUTO" />
        </id>
        <field name="name" column="name" type="string" />
        <field name="presentation" column="presentation" nullable="true" />
        <field name="code" column="code" type="string" />
    </entity>
    <class name="Acme\DemoBundle\Model\Product">
        <property name="name">
            <constraint name="NotBlank" />
            <constraint name="Length">
                <option name="min">2</option>
                <option name="max">255</option>
            </constraint>
        </property>

        <property name="code">
           <constraint name="NotBlank" />
           <constraint name="Regex">
                <option name="pattern">/^\d+/</option>
            </constraint>
            <constraint name="Length">
                <option name="min">2</option>
                <option name="max">255</option>
            </constraint>
        </property>
    </class>

The result is:

<form method="post" novalidate="novalidate">
    <div id="product">
        <div>
            <label for="product_name" class="required">Name</label><input type="text" id="product_name" name="product[name]" required="required"/>
        </div>
        <div>
            <label for="product_presentation" class="required">Presentation</label><input type="text" id="product_presentation" name="product[presentation]" required="required"/>
        </div>
        <div>
            <label for="product_code" class="required">Code</label><input type="text" id="product_code" name="product[code]" required="required"/>
        </div>
        <input type="hidden" id="product__token" name="product[_token]" value="..."/>
    </div>
    <button type="submit">Submit</button>
</form>

Expected:

  • Name: required=true, minlength=2, maxlength=255
  • Presentation: required=false
  • Code: required=true, pattern=/^\d+/, minlength=2, maxlength=255

Here is the symfony-standard fork to reproduce the issue:
https://github.com/marcospassos/symfony-standard/tree/master/src/Acme/DemoBundle
@marcospassos marcospassos mentioned this issue Feb 25, 2013
Closed
@webmozart
Copy link
Contributor

I discovered several issues with your fork:

  • (1) The data_class option is set to Acme\DemoBundle\Model\Product, which is not a valid entity class. Thus the Doctrine metadata is ignored when guessing. Things work fine if you set it to Acme\DemoBundle\Entity\Product
  • (2) The validator guesser gives no guess for the required option when a class property does not have any constraints, falling back to the default value of required, which is false.

(1) is fixable in your application, (2) is fixable in Symfony, but causes further problems:

  • (a) When you use guessing for non existing classes, the required option will be guessed to false.
  • (b) Point (a) could be avoided by not automatically creating ClassMetadata instances when a class is not mapped with constraints. Then validation of unmapped classes will result in an exception, unlike before, thus breaking BC.

Still the problem I see is the different default values for required. When we implement (a), required will be false by default when using guessing based on validation metadata and true when not using guessing.

So the question really is: Should we change the required option to default to true?

We could do so stepwise, i.e.

  1. make the default value configurable, leave it at true for 2.2
  2. set the default value to false in 2.3
  3. remove the configurability in 2.4

Thoughts?

@marcospassos
Copy link
Author

@bschussek Sorry, I noticed that I've not committed the last changes, you can check it now.

(a) Changing to a valid entity had no effect. Anyway, do you saw the validation.xml? The guesser lookup in it also, right?

(b) IMHO, removing the configurability will make it completely counter intuitive and hard to new users understand. Maybe, we need a better solution.

Please, check my fork again.

@webmozart
Copy link
Contributor

IMHO, removing the configurability will make it completely counter intuitive and hard to new users understand. Maybe, we need a better solution.

Sorry, I don't get the point here. What do you refer to?

@marcospassos
Copy link
Author

Sorry, I had misunderstood what you said about "remove the configurability in 2.4", I understand now and IMHO the stepwise seems reasonable.

Do you checked the (a) again?

@webmozart webmozart mentioned this issue Apr 19, 2013
Closed
This was referenced Oct 16, 2014
Closed
Closed
@webmozart
Copy link
Contributor

I'll close this in favor of #12018.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Form
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@webmozart @marcospassos
0