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

Extracted OptionsResolver component out of Form#3968

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
fabpot merged 12 commits intosymfony:masterfromwebmozart:options
May 15, 2012

Conversation

@webmozart
Copy link
Contributor

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -

Travis Build Status

This PR refactors the options-related code of the Form component into a separate component. See the README file for usage examples.

Copy link
Contributor

Choose a reason for hiding this comment

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

something seems wrong there, bad rebase?

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder how tests passed with that btw

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Fixed.

@schmittjoh
Copy link
Contributor

To me it seems like we have some redundancy with the Config/Definition component. I'm wondering if these two can/should be merged somehow?

Copy link
Contributor

Choose a reason for hiding this comment

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

Artefact of merge conflicts

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Fixed.

@kriswallsmith
Copy link
Contributor

I would also suggest merging this into the Config component. Its current name too closely resembles Python's optparser lib, which could create confusion.

Copy link
Contributor

Choose a reason for hiding this comment

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

seems useless to me

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

why? it does not for me.

Copy link
Contributor

Choose a reason for hiding this comment

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

then, why? because in both cases, you'll use the sorted array.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I only use the sorted array when throwing an exception. What is correct though is that sort() on an empty array should not have any performance impact.

Copy link
Contributor

Choose a reason for hiding this comment

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

Then, it's probably better to avoid a condition there.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Yes, I just fixed that.

@webmozart
Copy link
ContributorAuthor

Merge conflict artifacts are fixed now.

@schmittjoh Do we? Isn't the idea of the Config component to read complex configuration from different configuration providers? (YAML, XML, Annotations etc.)

The idea of this parser is to be highly performant and to be usable in simple classes. If this can be achieved with the Config component, I'm happy to learn more.

@schmittjoh
Copy link
Contributor

The config component is basically a super intelligent version of array_merge and the like.

About performance, I haven't really done any tests to say something about the impact. I think it's safe to say that it would be at least slower than your implementation in its current form due to the additional indirection. However, we could probably add a caching layer.

@webmozart
Copy link
ContributorAuthor

Have you checked the README I wrote? Are you sure the Config component is intended for the same purpose and notway too complex in this case?

Copy link
Member

Choose a reason for hiding this comment

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

same here. It looks more like an InvalidArgumentException

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Fixed.

@stof
Copy link
Member

You also forgot to update thereplace section of the root composer.json file.

And regarding doing such thing with the Config Definition stuff, it would be more difficult: it builds the tree of values with their defaults, and then merges stuff coming from different sources. The form component however receives defaults from different places (which also define the allowed keys at the same time) and then receives user options only once. And it needs to handle easily default values which depend from other values. So I think both implementations are useful for different needs (however, we could argue about making it a subnamespace in the Config component, but this would add yet another different stuff in it)

@jalliot
Copy link
Contributor

@bschussek You need to add this component to the main composer.json too.

@lsmith77
Copy link
Contributor

doesn't this overlap a bit with theTreeBuilder in the Config component?

@lsmith77
Copy link
Contributor

ah just saw@stof's comment .. i think the biggest argument against TreeBuilder is that it was designed for a very specific purpose and performance wasn't one of them. where as Form needs something that performs fast. so yeah i do see different use cases, but i don't think this means we should have a new component.

furthermore while i haven't read the code in details i am surprised it doesn't make use ofhttp://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.

Copy link
Contributor

Choose a reason for hiding this comment

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

typo: OPTIONS

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Fixed.

@webmozart
Copy link
ContributorAuthor

@stof,@jalliot: Fixed.

furthermore while i haven't read the code in details i am surprised it doesn't make use ofhttp://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.

@lsmith77: Because that's not what this component does. The key feature of this component is to resolve default values of options that depend on theconcrete values of other options. I invite you to read the README.

Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configurations from storage providers, such as the filesystem.

@webmozart
Copy link
ContributorAuthor

Note: Not all relevant code of this component is shown in the diff. The (crucial) Options and LazyOption classes have only been moved out of Form.

@lsmith77
Copy link
Contributor

Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configuration values from the filesystem (typically).

decoupled is all fine, but to me this feels a bit too granular. but i am just expressing a gut feeling here

@jalliot
Copy link
Contributor

I think too it should be included in the config component (maybe in a subnamespace). Indeed the behaviour is too different to be merged into the current component but its purpose is similar and is all aboutconfiguration (hence the name of the component). Otherwise we could also split the current Config component into smaller components as it seems to me there are already parts of it that are totally unrelated to each other.

@webmozart
Copy link
ContributorAuthor

@jalliot Can you go into detail which parts that are and what changes you suggest?

@kriswallsmith Any other naming suggestion?

@jalliot
Copy link
Contributor

@bschussek I don't know the current component well enough but that's the impression I had last time I looked at its code but I may be wrong.

@stof
Copy link
Member

@bschussek the Definition subnamespace of the Config component is standalone. It is not directly related to the Loader part

@webmozart
Copy link
ContributorAuthor

@stof So what do you recommend?

I think this is also a question of marketing. Is the Definition subnamespace intended to be used totally separately of the loaders? What are the use cases? If there are good use cases, it makes sense to me to extract the Definition part into a separate component. Otherwise not.

It is also a question of marketing, because the purpose of a component should be communicable in simple words (quoting@fabpot). The purpose of Config is (copied from the README):

Config provides the infrastructure for loading configurations from different data sources and optionally monitoring these data sources for changes. There are additional tools for validating, normalizing and handling of defaults that can optionally be used to convert from different formats to arrays.

I think this purpose is completely different than that of OptionsParser.

@stof
Copy link
Member

The current description itself shows the current state: what is advocated as the main goal of the component (and was the original part) is the loader stuff. But the Definition part (mentioned as "additional tools") is bigger in term of LOC

@webmozart
Copy link
ContributorAuthor

@stof: Yes, this is a fact, but what's your opinion? How do we proceed with this PR?

@stof
Copy link
Member

Well, my opinion is that the current Config component may deserve to be split into 2 components (as someone may need only part of it). But this would be a huge BC break.@fabpot what do you think ?

@webmozart
Copy link
ContributorAuthor

@fabpot Can we merge this?

@fabpot
Copy link
Member

@bschussek I'm +1 for this PR but as mentioned by@kriswallsmith, we must find another name asOptionsParser immediately make me think of something related to the CLI.

Copy link
Contributor

Choose a reason for hiding this comment

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

typo: Once read

@vicb
Copy link
Contributor

@bschussek if some of my comments make sense I can help implementing them.

Copy link
Member

Choose a reason for hiding this comment

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

this file should not be executable

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

It is not.. why should it be?

Copy link
Contributor

Choose a reason for hiding this comment

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

GH says it is:

...mponent/Form/Exception/InvalidOptionException.php → .../OptionsResolver/Exception/ExceptionInterface.php 100644 → 100755

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

How is it possible to display this information? It is not shown for me.

Copy link
Contributor

Choose a reason for hiding this comment

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

You fixed it in this commit:webmozart@d60626e

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Interesting. Thanks.

Copy link
Contributor

Choose a reason for hiding this comment

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

@travisbot
Copy link

This pull requestpasses (merged1c5f6c7 into46ffbd5).

Copy link
Member

Choose a reason for hiding this comment

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

This should be changed to5.3.3 as all other components min PHP version has been changed recently to this version.

@fabpot
Copy link
Member

Anything else before I merge this PR?

fabpot added a commit that referenced this pull requestMay 15, 2012
Commits-------95727ff [OptionsResolver] Updated PHP requirements to 5.3.31c5f6c7 [OptionsResolver] Fixed issues mentioned in the PR commentsd60626e [OptionsResolver] Fixed clear() and remove() method in Options class2b46975 [OptionsResolver] Fixed Options::replace() method16f7d20 [OptionsResolver] Improved implementation and clarity of the Options class6ce68b1 [OptionsResolver] Removed reference to non-existing property9c76750 [OptionsResolver] Fixed doc and block nesting876fd9b [OptionsResolver] Implemented fluid interface95454f5 [OptionsResolver] Fixed typos256b708 [OptionsParser] Renamed OptionsParser to OptionsResolver04522ca [OptionsParser] Added method replaceDefaults()b9d053e [Form] Moved Options classes to new OptionsParser componentDiscussion----------Extracted OptionsResolver component out of FormBug fix: noFeature addition: yesBackwards compatibility break: noSymfony2 tests pass: yesFixes the following tickets: -Todo: -![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=options)This PR refactors the options-related code of the Form component into a separate component. See the README file for usage examples.---------------------------------------------------------------------------by schmittjoh at 2012-04-17T18:11:03ZTo me it seems like we have some redundancy with the Config/Definition component. I'm wondering if these two can/should be merged somehow?---------------------------------------------------------------------------by kriswallsmith at 2012-04-17T18:14:44ZI would also suggest merging this into the Config component. Its current name too closely resembles Python's optparser lib, which could create confusion.---------------------------------------------------------------------------by bschussek at 2012-04-17T18:18:49ZMerge conflict artifacts are fixed now.@schmittjoh Do we? Isn't the idea of the Config component to read complex configuration from different configuration providers? (YAML, XML, Annotations etc.)The idea of this parser is to be highly performant and to be usable in simple classes. If this can be achieved with the Config component, I'm happy to learn more.---------------------------------------------------------------------------by schmittjoh at 2012-04-17T18:27:08ZThe config component is basically a super intelligent version of array_merge and the like.About performance, I haven't really done any tests to say something about the impact. I think it's safe to say that it would be at least slower than your implementation in its current form due to the additional indirection. However, we could probably add a caching layer.---------------------------------------------------------------------------by bschussek at 2012-04-17T18:31:22ZHave you checked the README I wrote? Are you sure the Config component is intended for the same purpose and not *way* too complex in this case?---------------------------------------------------------------------------by stof at 2012-04-17T18:51:14ZYou also forgot to update the ``replace`` section of the root composer.json file.And regarding doing such thing with the Config Definition stuff, it would be more difficult: it builds the tree of values with their defaults, and then merges stuff coming from different sources. The form component however receives defaults from different places (which also define the allowed keys at the same time) and then receives user options only once. And it needs to handle easily default values which depend from other values. So I think both implementations are useful for different needs (however, we could argue about making it a subnamespace in the Config component, but this would add yet another different stuff in it)---------------------------------------------------------------------------by jalliot at 2012-04-17T18:58:03Z@bschussek You need to add this component to the main composer.json too.---------------------------------------------------------------------------by lsmith77 at 2012-04-18T06:54:17Zdoesn't this overlap a bit with the ``TreeBuilder`` in the Config component?---------------------------------------------------------------------------by lsmith77 at 2012-04-18T06:59:12Zah just saw@stof's comment .. i think the biggest argument against TreeBuilder is that it was designed for a very specific purpose and performance wasn't one of them. where as Form needs something that performs fast. so yeah i do see different use cases, but i don't think this means we should have a new component.furthermore while i haven't read the code in details i am surprised it doesn't make use ofhttp://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.---------------------------------------------------------------------------by bschussek at 2012-04-18T08:10:49Z@stof,@jalliot: Fixed.> furthermore while i haven't read the code in details i am surprised it doesn't make use ofhttp://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.@lsmith77: Because that's not what this component does. The key feature of this component is to resolve default values of options that depend on the *concrete* values of other options. I invite you to read the README.Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configurations from storage providers, such as the filesystem.---------------------------------------------------------------------------by bschussek at 2012-04-18T08:18:48ZNote: Not all relevant code of this component is shown in the diff. The (crucial) Options and LazyOption classes have only been moved out of Form.---------------------------------------------------------------------------by lsmith77 at 2012-04-18T08:20:02Z> Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configuration values from the filesystem (typically).decoupled is all fine, but to me this feels a bit too granular. but i am just expressing a gut feeling here---------------------------------------------------------------------------by jalliot at 2012-04-18T08:34:03ZI think too it should be included in the config component (maybe in a subnamespace). Indeed the behaviour is too different to be merged into the current component but its purpose is similar and is all about *configuration* (hence the name of the component). Otherwise we could also split the current Config component into smaller components as it seems to me there are already parts of it that are totally unrelated to each other.---------------------------------------------------------------------------by bschussek at 2012-04-18T11:30:55Z@jalliot Can you go into detail which parts that are and what changes you suggest?@kriswallsmith Any other naming suggestion?---------------------------------------------------------------------------by jalliot at 2012-04-18T11:34:35Z@bschussek I don't know the current component well enough but that's the impression I had last time I looked at its code but I may be wrong.---------------------------------------------------------------------------by stof at 2012-04-18T19:30:43Z@bschussek the Definition subnamespace of the Config component is standalone. It is not directly related to the Loader part---------------------------------------------------------------------------by bschussek at 2012-04-19T09:32:48Z@stof So what do you recommend?I think this is also a question of marketing. Is the Definition subnamespace intended to be used totally separately of the loaders? What are the use cases? If there are good use cases, it makes sense to me to extract the Definition part into a separate component. Otherwise not.It is also a question of marketing, because the purpose of a component should be communicable in simple words (quoting@fabpot). The purpose of Config is (copied from the README):> Config provides the infrastructure for loading configurations from different data sources and optionally monitoring these data sources for changes. There are additional tools for validating, normalizing and handling of defaults that can optionally be used to convert from different formats to arrays.I think this purpose is completely different than that of OptionsParser.---------------------------------------------------------------------------by stof at 2012-04-19T11:39:50ZThe current description itself shows the current state: what is advocated as the main goal of the component (and was the original part) is the loader stuff. But the Definition part (mentioned as "additional tools") is bigger in term of LOC---------------------------------------------------------------------------by bschussek at 2012-04-19T11:55:17Z@stof: Yes, this is a fact, but what's your opinion? How do we proceed with this PR?---------------------------------------------------------------------------by stof at 2012-04-19T12:21:44ZWell, my opinion is that the current Config component may deserve to be split into 2 components (as someone may need only part of it). But this would be a huge BC break.@fabpot what do you think ?---------------------------------------------------------------------------by bschussek at 2012-04-23T10:14:57Z@fabpot Can we merge this?---------------------------------------------------------------------------by fabpot at 2012-05-10T06:45:20Z@bschussek I'm +1 for this PR but as mentioned by@kriswallsmith, we must find another name as `OptionsParser` immediately make me think of something related to the CLI.---------------------------------------------------------------------------by stof at 2012-05-10T06:47:45ZHowever, after thinking about it again, I would vote for keeping it in its own component instead of adding yet another independant part in Config, to avoid forcing Form users to get the whole Config component---------------------------------------------------------------------------by bschussek at 2012-05-10T09:09:36ZI'm having difficulties finding a better name. The main difference to CLI option parsers is that these actualy *parse* a string, while this class only receives an array of options (does not do any parsing). Otherwise both have the same purpose.A couple of other suggestions:* OptionsLoader (likely confused with our filesystem loaders)* OptionsResolver* OptionsMerger* OptionsMatcher (not accurate)* OptionsBuilder (likely confused with the builder pattern)* OptionsJoiner* OptionsBag (likely confused with the session bags)* OptionsConfig (likely confused with Config)* OptionsDefinition (likely confused with Config\Definition)* OptionsSpec* OptionsCombiner* OptionsInitializer* OptionsComposerThe difficulty is to find a name that best reflects its purpose:```$parser->setDefaults(...);$parser->setRequired(...);$parser->setOptional(...);$parser->setAllowedValues(...)$parser->parse($userOptions);```The only of the above examples that makes sense to me here is OptionsResolver -> resolve($userOptions).Ideas?---------------------------------------------------------------------------by stof at 2012-05-10T09:56:54ZOptionsResolver seems a better name than OptionsParser---------------------------------------------------------------------------by luxifer at 2012-05-10T09:59:45ZAgree with@stof---------------------------------------------------------------------------by r1pp3rj4ck at 2012-05-10T10:03:53ZI don't really like the plural in the name, but OptionsResolver seems better than OptionsParser. OptionResolver maybe?---------------------------------------------------------------------------by sstok at 2012-05-10T10:10:14Z@r1pp3rj4ck Options makes more sense as they can be nested/deeper, and thus are multiple.Agree with@stof also.---------------------------------------------------------------------------by r1pp3rj4ck at 2012-05-10T10:13:01Z@sstok well, we have multiple events too and the name is EventDispatcher, not EventsDispatcher. Actually none of the component names are plural.---------------------------------------------------------------------------by newicz at 2012-05-10T10:33:50ZOptionsResolver - I find it suggesting that there is some kind of problem to be resolved and there's not,maybe OptionsDefiner but it isn't good aswell this is a tough one
@fabpotfabpot merged commit95727ff intosymfony:masterMay 15, 2012
@travisbot
Copy link

This pull requestpasses (merged95727ff into46ffbd5).

Copy link
Contributor

Choose a reason for hiding this comment

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

@bschussek is this example working ?self from closure looks weird to me andisKnownMaleName is not defined

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

It is working, except for the static methods, which are indeed exemplary (and not defined by intention to keep the code short). Please improve the example if you feel like it.

Copy link
Member

Choose a reason for hiding this comment

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

doesself really work inside the closure ?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I don't think so. I didn't think of that when writing the sample.

Copy link
Contributor

Choose a reason for hiding this comment

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

;)

@jalliot
Copy link
Contributor

@fabpot Don't forget to create the new component repository on github (and PEAR?) and activate the packagist hook for it :)

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

Projects

None yet

Milestone

2.1

Development

Successfully merging this pull request may close these issues.

32 participants

@webmozart@schmittjoh@kriswallsmith@stof@jalliot@lsmith77@fabpot@luxifer@attilabukor@sstok@newicz@marijn@naderman@Sgoettschkes@immutef@o@jpgerdeman@ssmusoke@zlatio@alvarezmario@ubick@krymen@jmikola@travisbot@vicb@rande@andy-cox@stloyd@willdurand@jdreesen@yethee@Tobion

[8]ページ先頭

©2009-2025 Movatter.jp