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

[Form] Add FilterChoiceLoader + choice_filter option#28624

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

Closed
ro0NL wants to merge1 commit intosymfony:masterfromro0NL:choice-filter
Closed

[Form] Add FilterChoiceLoader + choice_filter option#28624

ro0NL wants to merge1 commit intosymfony:masterfromro0NL:choice-filter

Conversation

@ro0NL
Copy link
Contributor

@ro0NLro0NL commentedSep 27, 2018
edited
Loading

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#11847,#14072,#28607,#28542
LicenseMIT
Doc PRsymfony/symfony-docs#10413

I did it :) i understand form choice lists.. took me only 2 days 😂

But here it is, achoice_filter option for theChoiceType. Allowing to filter the list of choices independent from any choice loader / array.

This is no magic bullet. To truly optimize one should always prefer a filtered choice list (e.g. passing a query builder to the doctrine choice loader). But for built-in / pre-defined choice loaders, e.g. Intl, this is convenient.

Thanks to@sstok and@yceruto also.

yceruto, ogizanagi, and sstok reacted with laugh emojiyceruto, ogizanagi, and ottaviano reacted with hooray emoji
@stof
Copy link
Member

* fix callable argument consistency (`choice, key, value` ideally)

Looking at the places where you use the callable, you cannot do that, as you may only have the choice at that point.

@ro0NL
Copy link
ContributorAuthor

Ready 👍

};

$choiceFilterNormalizer =function (Options$options,$choiceFilter) {
if (null !==$choiceFilter && !\is_callable($choiceFilter)) {
Copy link
Contributor

@HeahDudeHeahDudeOct 9, 2018
edited
Loading

Choose a reason for hiding this comment

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

So if we pass a valid set of two values to filter out the list but the array happens to be callable this may break. Since it would add complexity to handle this edge case I suggest to either remove the support of arrays or document the limitation.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

not sure i understand

$form =$this->createForm(ChoiceType::class,null, ['choices' => [1,2,3],'choice_filter' => [3],]);

works as expected...

Copy link
Contributor

Choose a reason for hiding this comment

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

@ro0NL HashDude meant a choice_filter like this["ClassName", "methodName"] for this, is_callable might return true

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

i see, that's edgy yes :) 👍 for removing array support from me

@ro0NL
Copy link
ContributorAuthor

ro0NL commentedOct 11, 2018
edited
Loading

@HeahDude i've optimized it a bit, now it only creates a new loader in case a filter is given. To me that's reasonable in terms of caching, the result would differ per filter anyway.. so not really cacheable to me.

@ro0NL
Copy link
ContributorAuthor

to share cache between filtered/non-filtered choice lists we could add

ChoiceLoaderFactoryInterface::createLoaderFromChoices(iterable $choices): ChoiceLoaderInterface

then we can always use a cacheable loader (either given or created from choices) before decorating it and passing it tocreateListFromLoader. But im not sure it's worth it...

fabpot added a commit that referenced this pull requestOct 25, 2018
This PR was merged into the 4.2-dev branch.Discussion----------[Form] Deprecate TimezoneType regions option| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no     <!-- seehttps://symfony.com/bc -->| Deprecations? | yes| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->| Fixed tickets |#28848| License       | MIT| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->I know i've added this option myself in 4.1, but given my recent development for#28624 i realized it's an opinionated feaure, which can/should be solved on user-side (`choice_filter/choice_loader` and/or `group_by`).- blocks translations as we dont have them (see#28831)- blocks possibility of switching to Intl zones which doesnt really have this filter feature (see#28836)~While at it, i solved a few issues with `OptionsResolver` that is able to deprecate options as of 4.2 also.~ Fixed in#28878- when resolved trigger the deprecation- allow to opt-out from triggering the deprecation- dont trigger deprecation for default values (only given ones)Commits-------5cb532d [Form] Deprecate TimezoneType regions option
@jo66
Copy link

jo66 commentedFeb 4, 2019

@ro0NL choice_filter is nice option, will it be merged?

Pictor13 reacted with thumbs up emoji

@ro0NL
Copy link
ContributorAuthor

@jo66 rebased :) let's see if core wants to merge 👍

jo66 reacted with thumbs up emoji

@javiereguiluz
Copy link
Member

Could we restart the work on this to finish it? It looks like a cool feature for Symfony 5.0!

@ro0NLro0NL mentioned this pull requestJul 22, 2019
@ro0NL
Copy link
ContributorAuthor

I tend to close in favor of passing an optimizedchoice_loader (filtered and sorted as expected), that's the fastest way for core to move forward: no changes involved.

In#31593 i've also concluded this.

The only "issue" for core is the built-in Intl choice types, which manage the choice loader for us.

Im thinking of a feature specific to Intl to handle the sorting/ordering here. Much like concluded in#32657 (comment) as well.

@stof
Copy link
Member

@HeahDude didn't you start working on an alternative implementation at the choice factory level ? I cannot find a PR for it. You were supposed to open it as the result of the FOSSA Hackathon IIRC.

@yceruto
Copy link
Member

@stof do you mean this one#30994 ?

@ro0NL
Copy link
ContributorAuthor

closing this in favor of#32657 /#30994

@ro0NLro0NL closed thisSep 27, 2019
@ro0NLro0NL deleted the choice-filter branchSeptember 27, 2019 09:28
@nicolas-grekasnicolas-grekas modified the milestones:next,4.4Oct 27, 2019
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@stofstofstof left review comments

@xabbuhxabbuhxabbuh left review comments

+3 more reviewers

@HanmacHanmacHanmac left review comments

@ogizanagiogizanagiogizanagi left review comments

@HeahDudeHeahDudeHeahDude left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.4

Development

Successfully merging this pull request may close these issues.

11 participants

@ro0NL@stof@jo66@javiereguiluz@yceruto@Hanmac@xabbuh@ogizanagi@HeahDude@nicolas-grekas@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp