-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] Display general forms information on debug:form #24185
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
Conversation
protected function describeDefaults(array $options = array()) | ||
{ | ||
$data['builtin_form_types'] = $this->getCoreTypes(); | ||
$data['services_form_types'] = array_values(array_diff($options['types'], $data['builtin_form_types'])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
builtin types will be all from $options['types']
within Symfony\Component\Form\Extension\Core\Type\
namespace no? Isnt that more easy to do instead of getCoreTypes
hack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also i prefer services types to be shown above built in ones. Personal pref though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
builtin types will be all from
$options['types']
withinSymfony\Component\Form\Extension\Core\Type\ namespace
no?
Nope, only those registered, the most of them aren't services.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Perhaps add static getter for that in FormRegistry, as little new feat. But reflection is fine as well i guess xD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps add static getter for that in FormRegistry, as little new feat.
Not sure how to do that, because "types" is concern of FormExtensionInterface
instances and loadTypes()
method or types
property after initTypes()
in AbstractExtension
(both inaccessible directly) so would need hack it anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My idea was FormRegistry::getCoreTypes
with the implem. of CoreExtension::loadTypes
which in turn does simply return FormRegistry::getCoreTypes();
.
For this PR you'd use FormRegistry::getCoreTypes()
as well. CoreExtension::getTypes
might do also :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, still not sure if worth it just for debug purpose. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True 👍
c692654
to
5678081
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still a bit worried about the fact the command does only list types registered as a service, which can be a bit confusing for users not finding their own types or some third party ones. But the fact you explicit the "core types" and "services types" sections looks enough to me.
[33mBuilt-in form types[39m | ||
[33m-------------------[39m | ||
|
||
* Symfony\Component\Form\Extension\Core\Type\FormType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering: What about removing the namespace for core types when using the txt descriptor? (perhaps mentioning it only once above, in a comment or the section).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A long list of short words is also not ideal btw. But 👍 for using short names anyway. Perhaps play a bit with comma separated variants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Improved core types representation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice :)
5678081
to
01eda09
Compare
Screenshot updated! |
alpha order? |
01eda09
to
e418d14
Compare
@ogizanagi we know the path of installed bundles, we have best practices that say us the directory where would put the form types, what do you think about a discovery option to search subclasses of |
e418d14
to
efe4180
Compare
Just updating the help description. |
Form types could be in so many places, including not in a bundle at all. Searching them by convention, which is more a beginner best practice than a canon, probably isn't a satisfying enough solution. |
True, it was just a vague idea, I meant, Forms path best practices can be used first, later anywhere, but probably it would be too much. |
Convenience wise i like the discovery of types with At least passing an arbitrary FQCN, which is a form type, should be allowed. Discovery wise i wouldnt be against a lookup in |
I have another PR ready for debug a form type "option" but I'd like avoid conflicts later with this one. Please @symfony/deciders or reviewers? @chalasr since you're familiarized with the command, can I ask for your opinion? |
{ | ||
$coreTypes = $this->getCoreTypes(); | ||
|
||
$this->output->section('Built-in form types (Symfony\Component\Form\Extension\Core\Type)'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not bound to OutputInterface
but StyleInterface
. Are we being pragmatic here? Should we?
$output = $this->output instanceof StyleInterface ? $this->ouput : new SymfonyStyle($this->output);
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, we are subject to DescriptorInterface
signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thanks!
"Symfony\\Component\\Form\\Extension\\Core\\Type\\TimezoneType", | ||
"Symfony\\Component\\Form\\Extension\\Core\\Type\\UrlType" | ||
], | ||
"services_form_types": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
id sayservice_form_types
(no double pluralization)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
f846fc6
to
78d1780
Compare
78d1780
to
12d1a7f
Compare
Thanks Yonel. |
… (yceruto) This PR was merged into the 3.4 branch. Discussion ---------- [Form] Display general forms information on debug:form | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | -  When we run `bin/console debug:form` (without argument) all possible Form Component information is displayed. Commits ------- 12d1a7f Display form defaults on debug:form
…e (yceruto, ogizanagi) This PR was merged into the 3.4 branch. Discussion ---------- [Form] Display option definition from a given form type | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes (deps=high failure expected) | Fixed tickets | - | License | MIT | Doc PR | -  Show friendly message if typo:  complement of symfony/symfony#24185 Commits ------- d6d187d26e Add & use OptionResolverIntrospector 8bbb5e7884 Add debug:form type option
…e (yceruto, ogizanagi) This PR was merged into the 3.4 branch. Discussion ---------- [Form] Display option definition from a given form type | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes (deps=high failure expected) | Fixed tickets | - | License | MIT | Doc PR | -  Show friendly message if typo:  complement of #24185 Commits ------- d6d187d Add & use OptionResolverIntrospector 8bbb5e7 Add debug:form type option
When we run
bin/console debug:form
(without argument) all possible Form Component information is displayed.