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

[Form] Display general forms information on debug:form #24185

Merged
merged 1 commit into from Sep 15, 2017

Conversation

Projects
None yet
6 participants
@yceruto
Contributor

yceruto commented Sep 13, 2017

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 -

debug-form-defaults

When we run bin/console debug:form (without argument) all possible Form Component information is displayed.

@ogizanagi

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.

@yceruto

This comment has been minimized.

Show comment
Hide comment
@yceruto

yceruto Sep 13, 2017

Contributor

Screenshot updated!

Contributor

yceruto commented Sep 13, 2017

Screenshot updated!

@ro0NL

This comment has been minimized.

Show comment
Hide comment
@ro0NL

ro0NL Sep 13, 2017

Contributor

alpha order?

Contributor

ro0NL commented Sep 13, 2017

alpha order?

@yceruto

This comment has been minimized.

Show comment
Hide comment
@yceruto

yceruto Sep 13, 2017

Contributor

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...

@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 AbstractType using the Finder component? This operation we would only do it using --vvv option. (in another PR)

Contributor

yceruto commented Sep 13, 2017

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...

@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 AbstractType using the Finder component? This operation we would only do it using --vvv option. (in another PR)

@yceruto

This comment has been minimized.

Show comment
Hide comment
@yceruto

yceruto Sep 13, 2017

Contributor

Just updating the help description.

Contributor

yceruto commented Sep 13, 2017

Just updating the help description.

@ogizanagi

This comment has been minimized.

Show comment
Hide comment
@ogizanagi

ogizanagi Sep 14, 2017

Member

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 AbstractType using the Finder component?

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.

Member

ogizanagi commented Sep 14, 2017

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 AbstractType using the Finder component?

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.

@yceruto

This comment has been minimized.

Show comment
Hide comment
@yceruto

yceruto Sep 14, 2017

Contributor

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.

Contributor

yceruto commented Sep 14, 2017

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.

@ro0NL

This comment has been minimized.

Show comment
Hide comment
@ro0NL

ro0NL Sep 14, 2017

Contributor

Convenience wise i like the discovery of types with --discover or -v as proposed. Making this command so much more useful; we need to do something IMHO.

At least passing an arbitrary FQCN, which is a form type, should be allowed. Discovery wise i wouldnt be against a lookup in src/Form; src/**/Form; vendor/*/*/Form; vendor/*/*/**Form/.

Contributor

ro0NL commented Sep 14, 2017

Convenience wise i like the discovery of types with --discover or -v as proposed. Making this command so much more useful; we need to do something IMHO.

At least passing an arbitrary FQCN, which is a form type, should be allowed. Discovery wise i wouldnt be against a lookup in src/Form; src/**/Form; vendor/*/*/Form; vendor/*/*/**Form/.

@yceruto

This comment has been minimized.

Show comment
Hide comment
@yceruto

yceruto Sep 14, 2017

Contributor

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?

Contributor

yceruto commented Sep 14, 2017

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)');

This comment has been minimized.

@ro0NL

ro0NL Sep 14, 2017

Contributor

not bound to OutputInterface but StyleInterface. Are we being pragmatic here? Should we?

$output = $this->output instanceof StyleInterface ? $this->ouput : new SymfonyStyle($this->output);

?

@ro0NL

ro0NL Sep 14, 2017

Contributor

not bound to OutputInterface but StyleInterface. Are we being pragmatic here? Should we?

$output = $this->output instanceof StyleInterface ? $this->ouput : new SymfonyStyle($this->output);

?

This comment has been minimized.

@yceruto

yceruto Sep 14, 2017

Contributor

Yep, we are subject to DescriptorInterface signature.

@yceruto

yceruto Sep 14, 2017

Contributor

Yep, we are subject to DescriptorInterface signature.

This comment has been minimized.

@yceruto

yceruto Sep 14, 2017

Contributor

Fixed. Thanks!

@yceruto

yceruto Sep 14, 2017

Contributor

Fixed. Thanks!

@yceruto yceruto changed the title from [Form] Display form defaults in debug:form to [Form] Display forms information on debug:form Sep 14, 2017

@yceruto yceruto changed the title from [Form] Display forms information on debug:form to [Form] Display general forms information on debug:form Sep 14, 2017

@ro0NL

ro0NL approved these changes Sep 14, 2017

@ogizanagi

This comment has been minimized.

Show comment
Hide comment
@ogizanagi

ogizanagi Sep 15, 2017

Member

Thanks Yonel.

Member

ogizanagi commented Sep 15, 2017

Thanks Yonel.

@ogizanagi ogizanagi merged commit 12d1a7f into symfony:3.4 Sep 15, 2017

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
fabbot.io Your code looks good.
Details

ogizanagi added a commit that referenced this pull request Sep 15, 2017

feature #24185 [Form] Display general forms information on debug:form…
… (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        | -

![debug-form-defaults](https://user-images.githubusercontent.com/2028198/30436620-998103ca-993a-11e7-9873-31f042327374.png)

When we run `bin/console debug:form` (without argument) all possible Form Component information is displayed.

Commits
-------

12d1a7f Display form defaults on debug:form

@yceruto yceruto deleted the yceruto:debug_form_defaults branch Sep 15, 2017

symfony-splitter pushed a commit to symfony/form that referenced this pull request Oct 9, 2017

feature #24208 [Form] Display option definition from a given form typ…
…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        | -

![debug-form-option](https://user-images.githubusercontent.com/2028198/30569305-12a30738-9ca8-11e7-98b7-6eaf78d3d5a7.png)

Show friendly message if typo:
![debug-form-not-found](https://user-images.githubusercontent.com/2028198/30450999-83d58b56-9960-11e7-8705-b60ba33baf48.png)

complement of symfony/symfony#24185

Commits
-------

d6d187d26e Add & use OptionResolverIntrospector
8bbb5e7884 Add debug:form type option

fabpot added a commit that referenced this pull request Oct 9, 2017

feature #24208 [Form] Display option definition from a given form typ…
…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        | -

![debug-form-option](https://user-images.githubusercontent.com/2028198/30569305-12a30738-9ca8-11e7-98b7-6eaf78d3d5a7.png)

Show friendly message if typo:
![debug-form-not-found](https://user-images.githubusercontent.com/2028198/30450999-83d58b56-9960-11e7-8705-b60ba33baf48.png)

complement of #24185

Commits
-------

d6d187d Add & use OptionResolverIntrospector
8bbb5e7 Add debug:form type option

@fabpot fabpot referenced this pull request Oct 18, 2017

Merged

Release v3.4.0-BETA1 #24609

@fabpot fabpot referenced this pull request Oct 19, 2017

Merged

Release v4.0.0-BETA1 #24612

@yceruto yceruto referenced this pull request Feb 7, 2018

Closed

Symfony form information #4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment