Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[2.2] [Config] Better handling for numerical values:#4714

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@jeanmonod
Copy link
Contributor

  • New node type Integer and Float
  • New expressions: ifLessThan(), ifGreaterThan(), ifInRange(), ifNotInRange()

@fabpot
Copy link
Member

As I said on PR#4713, adding more method clutters the API without any big benefits. I'm -1 on the PR.

@jeanmonod
Copy link
ContributorAuthor

I have been discuss it with@schmittjoh at the sflive, he was thinking it could be a good addition.
IMHO I think that if we want to encourage the usage of bundle configuration validation, we should make it as easy as possible to use...

@jeanmonod
Copy link
ContributorAuthor

A real life example:

->scalarNode('max_nb_items')    ->validate()        ->ifTrue(function($v){            return !is_int($v) || (is_int($v) && $v<1);        })        ->thenInvalid('Must be a positive integer')    ->end()->end()

could be replaced by

->integerNode('max_nb_items')    ->validate()        ->ifLessThan(1);        ->thenInvalid('Must be a positive integer')    ->end()->end()

@gnutix
Copy link
Contributor

I agree with@jeanmonod on this matter, the bundle configuration validation is already kind of a hassle to understand (and read), so it would be a good addition IMHO.

@fabpot
Copy link
Member

@schmittjoh What's your point of view?

@schmittjoh
Copy link
Contributor

The integer and float nodes are valuable additions imo which I wanted to add myself several times but simply did not have the time for.

As for the changes to the expression builder, I was not really passionate about them in Paris, but I did not mind either way. However, looking at this PR, I think they would be better implemented as methods on the definition builders, and validated directly by the nodes:

$builder->integerNode('foo')->range(1,4)->end();$builder->integerNode('foo')->mustBeGreaterThan(5)->end();

This will also allow for these constraints to be introspected and added to generated documentation.

@fabpot
Copy link
Member

@jeanmonod Can you take into account the comments by@schmittjoh?

@jeanmonod
Copy link
ContributorAuthor

@fabpot Yes, I will try to move those 4 checks.

@schmittjoh If I put those tests into the ScalarNodeDefinition did you think it's ok? And did I have to make anything special for the documentation introspection?

@schmittjoh
Copy link
Contributor

You can take a look at the EnumNodeDefinition, and the EnumNode. They are
pretty simple, and should give you a good idea of how to implement it.

On Tue, Jul 3, 2012 at 9:46 PM, Jeanmonod David <
reply@reply.github.com

wrote:

@fabpot Yes, I will try to move those 4 checks.

@schmittjoh If I put those tests into the ScalarNodeDefinition did you
think it's ok? And did I have to make anything special for the
documentation introspection?


Reply to this email directly or view it on GitHub:
#4714 (comment)

@jeanmonod
Copy link
ContributorAuthor

OK, I just refactor as requested. At the end, I didn't add the range() check. It can be easily done by chaining min and max, like this:

$builder->integerNode('foo')->min(1)->max(4)->end();

@schmittjoh can you have a look?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you move all of this code to an abstract sub-class,NumericNode for example?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Yes, this can be done, but is it really useful? All scalars can all handle the min max, something like:

$builder->stringNode('word_range')->min('a')->max('d')->end();

Can be valid (even if nobody is never going to use it...)

Copy link
Contributor

Choose a reason for hiding this comment

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

As it does not apply to all scalars, I think it should be a sub-class. For strings, I think a regular expression would be more intuitive :)

@schmittjoh
Copy link
Contributor

Have you tested the builder API? Did you maybe forget to commit something?

@jeanmonod
Copy link
ContributorAuthor

Yes you are right, I forget the definition

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also allow integers here, and cast them?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Yes, why not. Where is the best place for doing that? In the finalizeValue() method?

Copy link
Contributor

Choose a reason for hiding this comment

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

normalizeValue would be the place.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I'm not sure about that. In BaseNode::normalize() it first validate the type and then it call the normalizeValue(), so the type check fail before I'm able to cast it to float...
What I can do is to be less restrictive in the validateType(). What do you prefer?

@jeanmonod
Copy link
ContributorAuthor

OK, I realize now that I misunderstood the concept. I was thinking that a node was able to do self validation. But no, I will have to move my code to the node definition. So let's wait for a new commit...

Copy link
Member

Choose a reason for hiding this comment

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

please remove these extra empty lines

@jeanmonod
Copy link
ContributorAuthor

@schmittjoh I just push the move to definition and the new abstract class Numeric. Can you review it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Missing blank line here.

@jeanmonod
Copy link
ContributorAuthor

@schmittjoh,@fabpot
I fix all the mention points, can you have a look at the final result?

@schmittjoh
Copy link
Contributor

There are still some excessive blank lines if you want to be perfect, but overall looks good now.

@jeanmonod
Copy link
ContributorAuthor

@schmittjoh I think the comments of@Baachi are not well placed in the diff. I execute php-cs-fix on all code, so level of perfectness is already good ;)

@fabpot Do you want some more complements before merging?

@fabpot
Copy link
Member

@jeanmonod I'm going to review the code once more and it will be merged for 2.2. Thanks for your work.

@fabpot
Copy link
Member

@jeanmonod Can you squash your commits before I merge? Thanks.

Copy link
Contributor

Choose a reason for hiding this comment

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

need a trailing dot.

 * New node type Integer and Float * New expressions: min() and max()
@jeanmonod
Copy link
ContributorAuthor

@fabpot Squash done

Copy link
Contributor

Choose a reason for hiding this comment

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

missing phpdoc for \InvalidArgumentException (same onmin).

@fabpot
Copy link
Member

@jeanmonod One last thing: can you submit a PR on symfony/symfony-docs that update the documentation with the new possibilities?

@jeanmonod
Copy link
ContributorAuthor

@fabpot OK, Documentation PR done here:symfony/symfony-docs#1732

fabpot added a commit that referenced this pull requestSep 20, 2012
Commits-------71db836 Better config validation handling for numerical values:  * New node type Integer and Float  * New expressions: min() and max()Discussion----------[2.2] [Config] Better handling for numerical values:* New node type Integer and Float* New expressions: ifLessThan(), ifGreaterThan(), ifInRange(), ifNotInRange()---------------------------------------------------------------------------by fabpot at 2012-07-03T08:50:22ZAs I said on PR#4713, adding more method clutters the API without any big benefits. I'm -1 on the PR.---------------------------------------------------------------------------by jeanmonod at 2012-07-03T08:54:36ZI have been discuss it with@schmittjoh at the sflive, he was thinking it could be a good addition.IMHO I think that if we want to encourage the usage of bundle configuration validation, we should make it as easy as possible to use...---------------------------------------------------------------------------by jeanmonod at 2012-07-03T08:59:42ZA real life example:    ->scalarNode('max_nb_items')        ->validate()            ->ifTrue(function($v){                return !is_int($v) || (is_int($v) && $v<1);            })            ->thenInvalid('Must be a positive integer')        ->end()    ->end()could be replaced by    ->integerNode('max_nb_items')        ->validate()            ->ifLessThan(1);            ->thenInvalid('Must be a positive integer')        ->end()    ->end()---------------------------------------------------------------------------by gnutix at 2012-07-03T09:03:06ZI agree with@jeanmonod on this matter, the bundle configuration validation is already kind of a hassle to understand (and read), so it would be a good addition IMHO.---------------------------------------------------------------------------by fabpot at 2012-07-03T10:54:32Z@schmittjoh What's your point of view?---------------------------------------------------------------------------by schmittjoh at 2012-07-03T14:10:37ZThe integer and float nodes are valuable additions imo which I wanted to add myself several times but simply did not have the time for.As for the changes to the expression builder, I was not really passionate about them in Paris, but I did not mind either way. However, looking at this PR, I think they would be better implemented as methods on the definition builders, and validated directly by the nodes:```php$builder->integerNode('foo')->range(1, 4)->end();$builder->integerNode('foo')->mustBeGreaterThan(5)->end();```This will also allow for these constraints to be introspected and added to generated documentation.---------------------------------------------------------------------------by fabpot at 2012-07-03T17:57:25Z@jeanmonod Can you take into account the comments by@schmittjoh?---------------------------------------------------------------------------by jeanmonod at 2012-07-03T19:40:24Z@fabpot Yes, I will try to move those 4 checks.@schmittjoh If I put those tests into the ScalarNodeDefinition did you think it's ok? And did I have to make anything special for the documentation introspection?---------------------------------------------------------------------------by schmittjoh at 2012-07-03T19:56:00ZYou can take a look at the EnumNodeDefinition, and the EnumNode. They arepretty simple, and should give you a good idea of how to implement it.On Tue, Jul 3, 2012 at 9:46 PM, Jeanmonod David <reply@reply.github.com> wrote:>@fabpot Yes, I will try to move those 4 checks.>>@schmittjoh If I put those tests into the ScalarNodeDefinition did you> think it's ok? And did I have to make anything special for the> documentation introspection?>> ---> Reply to this email directly or view it on GitHub:>#4714 (comment)>---------------------------------------------------------------------------by jeanmonod at 2012-07-03T21:37:18ZOK, I just refactor as requested. At the end, I didn't add the range() check. It can be easily done by chaining min and max, like this:    $builder->integerNode('foo')->min(1)->max(4)->end();@schmittjoh can you have a look?---------------------------------------------------------------------------by schmittjoh at 2012-07-03T21:48:17ZHave you tested the builder API? Did you maybe forget to commit something?---------------------------------------------------------------------------by jeanmonod at 2012-07-03T21:52:45ZYes you are right, I forget the definition---------------------------------------------------------------------------by jeanmonod at 2012-07-03T22:15:45ZOK, I realize now that I misunderstood the concept. I was thinking that a node was able to do self validation. But no, I will have to move my code to the node definition. So let's wait for a new commit...---------------------------------------------------------------------------by jeanmonod at 2012-07-06T06:13:55Z@schmittjoh I just push the move to definition and the new abstract class Numeric. Can you review it?---------------------------------------------------------------------------by jeanmonod at 2012-07-10T05:12:59Z@schmittjoh,@fabpotI fix all the mention points, can you have a look at the final result?---------------------------------------------------------------------------by schmittjoh at 2012-07-10T06:38:20ZThere are still some excessive blank lines if you want to be perfect, but overall looks good now.---------------------------------------------------------------------------by jeanmonod at 2012-07-10T07:05:54Z@schmittjoh I think the comments of@Baachi are not well placed in the diff. I execute php-cs-fix on all code, so level of perfectness is already good ;)@fabpot Do you want some more complements before merging?---------------------------------------------------------------------------by fabpot at 2012-07-10T07:07:21Z@jeanmonod I'm going to review the code once more and it will be merged for 2.2. Thanks for your work.---------------------------------------------------------------------------by fabpot at 2012-09-18T13:58:48Z@jeanmonod Can you squash your commits before I merge? Thanks.---------------------------------------------------------------------------by jeanmonod at 2012-09-18T14:36:59Z@fabpot Squash done---------------------------------------------------------------------------by fabpot at 2012-09-19T04:07:13Z@jeanmonod One last thing: can you submit a PR on symfony/symfony-docs that update the documentation with the new possibilities?---------------------------------------------------------------------------by jeanmonod at 2012-09-20T05:32:01Z@fabpot OK, Documentation PR done here:symfony/symfony-docs#1732
@fabpotfabpot merged commit71db836 intosymfony:masterSep 20, 2012
symfony-splitter pushed a commit to symfony/config that referenced this pull requestFeb 23, 2016
Commits-------71db836 Better config validation handling for numerical values:  * New node type Integer and Float  * New expressions: min() and max()Discussion----------[2.2] [Config] Better handling for numerical values:* New node type Integer and Float* New expressions: ifLessThan(), ifGreaterThan(), ifInRange(), ifNotInRange()---------------------------------------------------------------------------by fabpot at 2012-07-03T08:50:22ZAs I said on PR #4713, adding more method clutters the API without any big benefits. I'm -1 on the PR.---------------------------------------------------------------------------by jeanmonod at 2012-07-03T08:54:36ZI have been discuss it with@schmittjoh at the sflive, he was thinking it could be a good addition.IMHO I think that if we want to encourage the usage of bundle configuration validation, we should make it as easy as possible to use...---------------------------------------------------------------------------by jeanmonod at 2012-07-03T08:59:42ZA real life example:    ->scalarNode('max_nb_items')        ->validate()            ->ifTrue(function($v){                return !is_int($v) || (is_int($v) && $v<1);            })            ->thenInvalid('Must be a positive integer')        ->end()    ->end()could be replaced by    ->integerNode('max_nb_items')        ->validate()            ->ifLessThan(1);            ->thenInvalid('Must be a positive integer')        ->end()    ->end()---------------------------------------------------------------------------by gnutix at 2012-07-03T09:03:06ZI agree with@jeanmonod on this matter, the bundle configuration validation is already kind of a hassle to understand (and read), so it would be a good addition IMHO.---------------------------------------------------------------------------by fabpot at 2012-07-03T10:54:32Z@schmittjoh What's your point of view?---------------------------------------------------------------------------by schmittjoh at 2012-07-03T14:10:37ZThe integer and float nodes are valuable additions imo which I wanted to add myself several times but simply did not have the time for.As for the changes to the expression builder, I was not really passionate about them in Paris, but I did not mind either way. However, looking at this PR, I think they would be better implemented as methods on the definition builders, and validated directly by the nodes:```php$builder->integerNode('foo')->range(1, 4)->end();$builder->integerNode('foo')->mustBeGreaterThan(5)->end();```This will also allow for these constraints to be introspected and added to generated documentation.---------------------------------------------------------------------------by fabpot at 2012-07-03T17:57:25Z@jeanmonod Can you take into account the comments by@schmittjoh?---------------------------------------------------------------------------by jeanmonod at 2012-07-03T19:40:24Z@fabpot Yes, I will try to move those 4 checks.@schmittjoh If I put those tests into the ScalarNodeDefinition did you think it's ok? And did I have to make anything special for the documentation introspection?---------------------------------------------------------------------------by schmittjoh at 2012-07-03T19:56:00ZYou can take a look at the EnumNodeDefinition, and the EnumNode. They arepretty simple, and should give you a good idea of how to implement it.On Tue, Jul 3, 2012 at 9:46 PM, Jeanmonod David <reply@reply.github.com> wrote:>@fabpot Yes, I will try to move those 4 checks.>>@schmittjoh If I put those tests into the ScalarNodeDefinition did you> think it's ok? And did I have to make anything special for the> documentation introspection?>> ---> Reply to this email directly or view it on GitHub:>symfony/symfony#4714 (comment)>---------------------------------------------------------------------------by jeanmonod at 2012-07-03T21:37:18ZOK, I just refactor as requested. At the end, I didn't add the range() check. It can be easily done by chaining min and max, like this:    $builder->integerNode('foo')->min(1)->max(4)->end();@schmittjoh can you have a look?---------------------------------------------------------------------------by schmittjoh at 2012-07-03T21:48:17ZHave you tested the builder API? Did you maybe forget to commit something?---------------------------------------------------------------------------by jeanmonod at 2012-07-03T21:52:45ZYes you are right, I forget the definition---------------------------------------------------------------------------by jeanmonod at 2012-07-03T22:15:45ZOK, I realize now that I misunderstood the concept. I was thinking that a node was able to do self validation. But no, I will have to move my code to the node definition. So let's wait for a new commit...---------------------------------------------------------------------------by jeanmonod at 2012-07-06T06:13:55Z@schmittjoh I just push the move to definition and the new abstract class Numeric. Can you review it?---------------------------------------------------------------------------by jeanmonod at 2012-07-10T05:12:59Z@schmittjoh,@fabpotI fix all the mention points, can you have a look at the final result?---------------------------------------------------------------------------by schmittjoh at 2012-07-10T06:38:20ZThere are still some excessive blank lines if you want to be perfect, but overall looks good now.---------------------------------------------------------------------------by jeanmonod at 2012-07-10T07:05:54Z@schmittjoh I think the comments of@Baachi are not well placed in the diff. I execute php-cs-fix on all code, so level of perfectness is already good ;)@fabpot Do you want some more complements before merging?---------------------------------------------------------------------------by fabpot at 2012-07-10T07:07:21Z@jeanmonod I'm going to review the code once more and it will be merged for 2.2. Thanks for your work.---------------------------------------------------------------------------by fabpot at 2012-09-18T13:58:48Z@jeanmonod Can you squash your commits before I merge? Thanks.---------------------------------------------------------------------------by jeanmonod at 2012-09-18T14:36:59Z@fabpot Squash done---------------------------------------------------------------------------by fabpot at 2012-09-19T04:07:13Z@jeanmonod One last thing: can you submit a PR on symfony/symfony-docs that update the documentation with the new possibilities?---------------------------------------------------------------------------by jeanmonod at 2012-09-20T05:32:01Z@fabpot OK, Documentation PR done here:symfony/symfony-docs#1732
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

8 participants

@jeanmonod@fabpot@gnutix@schmittjoh@pborreli@stof@Tobion@Baachi

[8]ページ先頭

©2009-2025 Movatter.jp