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

Appearance settings

Commit 1bfb810

Browse filesBrowse files
committed
minor #32400 [Form] Name related PHPDoc fixes (vudaltsov)
This PR was merged into the 3.4 branch. Discussion ---------- [Form] Name related PHPDoc fixes | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | relates to #32179 | License | MIT | Doc PR | n/a As I started working on #32179 in #32237, I noticed some PHPDoc inconsistencies around the form's name. I have researched the issue thoroughly and here's my proposal: 1. All "factory" methods (`FormFactory::create*`, `ResolvedFormType::createBuilder`, `FormBuilder::create|add`, `Form::add`) currently accept string and integer names. This should not be deprecated, because it's very convenient and natural to pass ints when adding children to types like `ChoiceType` or `CollectionType`. 1. None of the "factory" methods explicitly accepts `null` as a name, although passing `null` works the same as passing `''`. I consider passing `null` in this case to be ugly, so I corrected the builder's constructors mentioning `null` as a possible argument. One should pass an empty string `''` when creating such a form. We could also deprecate passing `null` in a PR targeting 4.4. 1. Currently the name becomes a string in the builder's (or config builder's) constructor. Which means that `FormConfigInterface::getName` always returns a string and thus the form's `$name` property is always a string. All related checks and PHPDocs should be corrected. 1. The "children accessors" (`Form::has|get|remove`, `FormBuilder::has|get|remove`) should accept both strings and ints because they are array-accessible by design (so it does not really matter, if the key is a string or an int). If it's valid to have `$collectionForm->add(1, ItemType::class)`, then it should be valid to do `$collectionForm->get(1)`. And it works in code, but is not mentioned in the PHPDoc. ping @nicolas-grekas , @xabbuh , @HeahDude Commits ------- eae95c4 PHPDoc fixes
2 parents bbff632 + eae95c4 commit 1bfb810
Copy full SHA for 1bfb810

File tree

1 file changed

+3
-3
lines changed
Filter options

1 file changed

+3
-3
lines changed

‎src/Symfony/Component/Form/Form.php

Copy file name to clipboardExpand all lines: src/Symfony/Component/Form/Form.php
+3-3Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -140,9 +140,9 @@ class Form implements \IteratorAggregate, FormInterface
140140
private $lockSetData = false;
141141

142142
/**
143-
* @var string|int|null
143+
* @var string
144144
*/
145-
private $name;
145+
private $name = '';
146146

147147
/**
148148
* @var bool Whether the form inherits its underlying data from its parent
@@ -211,7 +211,7 @@ public function getPropertyPath()
211211
return $this->propertyPath;
212212
}
213213

214-
if (null === $this->name || '' === $this->name) {
214+
if ('' === $this->name) {
215215
return null;
216216
}
217217

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.