This PR was merged into the master branch.
Commits
-------
cda1621 Move FormInterface too
0544351 Move DeprecationErrorHandler to Test folder so it's not removed when building the zip file
f56a2b9Fix#6374 move FormBuilderInterface from Tests to Test
Discussion
----------
Fix#6374 move FormBuilderInterface from Tests to Test
---------------------------------------------------------------------------
by fabpot at 2012-12-16T07:47:55Z
Are there any other classes in the tests that might be useful for testing userland forms? ping @bschussek
---------------------------------------------------------------------------
by colinfrei at 2012-12-16T08:24:51Z
The DeprecationErrorHandler will need to be in the Test directory as well, as its handleBC method is used for handling BC code that's not in tests.
---------------------------------------------------------------------------
by colinfrei at 2012-12-16T09:06:51Z
Wanted to make a pull request to tvlooy's branch with the DeprecationErrorHandler stuff, but can't figure out how to do that - the commit is here: ec56379042
---------------------------------------------------------------------------
by stof at 2012-12-16T19:53:59Z
@fabpot The other extending interfaces provided for mocking purpose (as mocking an interface extending ``Traversable`` directly does not work). So we have FormInterface too at least
* 2.1:
[Console] Add support for parsing terminal width/height on localized windows, fixes#5742
[Form] Fixed treatment of countables and traversables in Form::isEmpty()
refactor ControllerNameParser
[Form] Fixed FileType not to throw an exception when bound empty
- Test undefined index #
Maintain array structure
Check if key # is defined in $value
Update src/Symfony/Component/Validator/Resources/translations/validators.pl.xlf
Commits
-------
eb2eba1 [Form] don't allow users to force exceptions by submitting unexpected data
Discussion
----------
[Form] don't allow users to force exceptions by submitting unexpected data
fix#5334
This makes it more fault-tolerant by simply ignoring wrong stuff from hackers.
@bschussek: I didn't find any other UnexpectedTypeExceptions that could be invoked by simply submitting unexpected data. But I'm not 100% sure that there aren't any indirectly invokeable, e.g. in some listeners.
---------------------------------------------------------------------------
by stof at 2012-08-24T22:34:52Z
a test is missing for this.
---------------------------------------------------------------------------
by Tobion at 2012-08-24T23:02:26Z
@stof true, I will add one
---------------------------------------------------------------------------
by Tobion at 2012-08-25T13:51:23Z
Added test.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:07:37Z
👍
Could you please squash the commits?
---------------------------------------------------------------------------
by Tobion at 2012-08-29T13:43:52Z
Done.
Commits
-------
7e8ab54 [Form] raise OutOfBoundsException instead of InvalidArgumentException for inexistent form childs to be in line with PropertyPath
Discussion
----------
[Form] raise OutOfBoundsException instead of InvalidArgumentException in Form::get
BC break: yes
Raise OutOfBoundsException instead of InvalidArgumentException in Form::get for inexistent form childs to be in line with PropertyPath, which also uses OutOfBoundsException for invalid indexes. OutOfBoundsException fits much better as it extends RuntimeException instead of LogicException and this error can typically not be detected at compile time.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:01:01Z
👍
---------------------------------------------------------------------------
by stloyd at 2012-08-29T11:07:51Z
Shouldn't this change be noted in upgrade file ?
---------------------------------------------------------------------------
by stof at 2012-08-29T11:23:04Z
it should (and in the changelog of the component)
Commits
-------
0186731 [Form] removed hasParent from FormInterface and deprecated its use
Discussion
----------
[Form] removed hasParent from FormInterface and deprecated its use
There are already 2 alternatives with getParent() and isRoot(), so a third one with similar semantics is confusing and unneeded.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:11:11Z
👍
Commits
-------
492c990 [Form] optimized PropertyPathMapper to invoke the expensive property path less often
47a8bbd [Form] optimized the binding of child forms and calculation of extra data
8d45539 [Form] refactor Form::bind to save 7 assignments
Discussion
----------
[Form] refactor Form::bind to save 7 assignments and a complete loop
---------------------------------------------------------------------------
by stof at 2012-08-24T23:45:18Z
the new code is not equivalent. See travis for the proof.
---------------------------------------------------------------------------
by Tobion at 2012-08-25T01:50:41Z
@stof fixed, I had to reduce the refactoring a little
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:05:52Z
👍
Commits
-------
d5eb4f7 [Form] fix phpdoc of Form::hasErrors
5cb8264 [Form] deprecated Form::hasErrors that isn't part of the Interface
Discussion
----------
[Form] deprecated Form::hasErrors that isn't part of the Interface
This method is not part of FormInterface, so I deprecated it as it cannot be used reliably. This is consistent with other hassers that were deprecated like `hasChildren` where one should use `count` instead.
---------------------------------------------------------------------------
by stof at 2012-08-26T19:11:19Z
You should deprecate it, not remove it
---------------------------------------------------------------------------
by Tobion at 2012-08-26T19:17:35Z
oh right. I thought it was added in 2.1 and thus can be removed but it's also in 2.0.
Done.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:00:32Z
👍
Commits
-------
24b764e [Form] Fixed issues mentioned in the PR
9216816 [Form] Turned Twig filters into tests
310f985 [Form] Added a layer of 2.0 BC methods to FormView and updated UPGRADE and CHANGELOG
5984b18 [Form] Precalculated the closure for deciding whether a choice is selected (PHP +30ms, Twig +30ms)
5dc3c39 [Form] Moved the access to templating helpers out of the choice loop for performance reasons (PHP +100ms)
0ef9acb [Form] Moved the method isChoiceSelected() to the ChoiceView class (PHP +150ms)
8b72766 [Form] Tweaked the generation of option tags for performance (PHP +200ms, Twig +50ms)
400c95b [Form] Replace methods in ChoiceView by public properties (PHP +100ms, Twig +400ms)
d072f35 [Form] The properties of FormView are now accessed directly in order to increase performance (PHP +200ms, Twig +150ms)
Discussion
----------
[Form] Made FormView and ChoiceView properties public for performance reasons
Bug fix: no
Feature addition: no
Backwards compatibility break: **yes**
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR changes the access to properties of `FormView` and `ChoiceView` objects from getters to direct property accesses. On [my example form](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1) this improves rendering performance for **300ms** with PHP templates and **550ms** with Twig on my local machine.
Unfortunately, this breaks BC both with 2.0 and with the current master in Form Types and PHP templates. Twig templates are not affected by this change.
2.0:
```
$formView->set('my_var', 'foobar');
$formView->get('my_var');
$formView->getChild('childName');
$formView['childName'];
```
master:
```
$formView->setVar('my_var', 'foobar');
$formView->getVar('my_var');
$formView->get('childName');
$formView['childName'];
```
this PR:
```
$formView->vars['my_var'] = 'foobar';
$formView->vars['my_var'];
$formView->children['childName'];
$formView['childName'];
```
Should we add methods to keep BC with 2.0?
The second part of this PR contains improvements to the rendering of choice fields. These gain another **~500ms** for PHP templates and **80ms** for Twig. These improvements are BC, unless you overwrote the block "choice_widget_options" in your form themes which then needs to be adapted.
**Update:**
The PR now includes a BC layer for 2.0.
---------------------------------------------------------------------------
by stof at 2012-07-21T11:37:41Z
@bschussek couldn't we keep the getters and setters for BC even if the rendering accesses the public properties directly ?
---------------------------------------------------------------------------
by bschussek at 2012-07-21T11:52:33Z
@stof A BC layer for 2.0 is now included. People who upgraded to master already unfortunately need to adapt their code.
---------------------------------------------------------------------------
by sstok at 2012-07-21T12:40:57Z
👍
Commits
-------
9c94b48 [Form] Fixed the "data" option to supersede default data set in the model
Discussion
----------
[Form] Fixed the "data" option to supersede default data set in the model
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3899
Todo: -
The error message on type mismatch is a bit obscure:
The form's view data is expected to be an instance of class Samson\Bundle\TRSBundle\Entity\Labour, but has the type object. You can avoid this error by setting the "data_class" option to null or by adding a view transformer that transforms object to Samson\Bundle\TRSBundle\Entity\Labour.
This commit changes it to:
The form's view data is expected to be an instance of class Samson\Bundle\TRSBundle\Entity\Labour, but is an instance of Closure. You can avoid this error by setting the "data_class" option to null or by adding a view transformer that transforms an instance of Closure to an instance of Samson\Bundle\TRSBundle\Entity\Labour.
CSRF fields are now only added when the view is built. For this reason we already know if
the form is the root form and avoid to create unnecessary CSRF fields for nested fields.
Commits
-------
e6577de Added a 'post validation' event to the form component.
Discussion
----------
[Form] Add post-validate event
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: n/a
Fixes the following tickets: n/a
Todo: n/a
---------------------------------------------------------------------------
by fabpot at 2012-03-02T20:34:18Z
ping @bschussek
---------------------------------------------------------------------------
by vicb at 2012-03-04T09:19:53Z
I think this is a good idea (It was something missing to properly handle PersistentFile i.e. you should not persist invalid files)
---------------------------------------------------------------------------
by vicb at 2012-03-09T22:35:26Z
@jankramer please remove the second commit from this PR (see http://symfony.com/doc/current/contributing/code/patches.html) in order to make this mergeable.
---------------------------------------------------------------------------
by jankramer at 2012-03-10T09:26:04Z
@vicb done, sorry about that commit: overlooked the fact that it was on the same branch...
Commits
-------
de253dd [Form] read_only and disabled attributes
Discussion
----------
[Form] read_only and disabled attributes (closes#1974)
1. Removed ``readOnly`` property from ``Form``, as it is no longer required
2. Introduced ``disabled`` property to ``Form``, behaves exactly like ``readOnly`` used to
3. Added ``disabled`` property to fields, defaults to ``false``, renders as ``disabled="disabled"``
4. A field with positive ``read_only`` property now renders as ``readonly="readonly"``
---------------------------------------------------------------------------
by helmer at 2012-01-26T17:46:17Z
I changed ``Form`` and ``FormBuilder`` property ``readOnly`` to ``disabled``. On second thought, this is perhaps not such good change - while readOnly somewhat implied the use-case, disabled no longer does.
Perhaps something else, like ``bindable`` (as not to confuse with read_only attribute of Fields)?
@bschussek, others, any thoughts?
---------------------------------------------------------------------------
by bschussek at 2012-01-31T06:53:59Z
Please prefix commits with the affected component, if applicable.
---------------------------------------------------------------------------
by helmer at 2012-01-31T08:41:03Z
@bschussek Prefixed. Please also see see to [this question](https://github.com/symfony/symfony/pull/3193#issuecomment-3673074)
Commits
-------
601d462 [Form] Added getValidators() to Form class
Discussion
----------
[Form] Added getValidators() to Form class
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
I am working implementing client side validation in a bundle that adds validation rules via a form builder. I am currently unable to pull the validators from the Form class which is making the implementation incredibly difficult.
I noticed that the transformers are currently exposed and based on some feedback I got on IRC I am guessing these weren't exposed simply because no one needed them at the time.
---------------------------------------------------------------------------
by mlively at 2011-12-28T20:54:41Z
Side note: It would be incredibly helpful to have this in the current branch of symfony. I implemented it on master because it is a new feature, but I would be more than happy to patch it into 2.0 if you would like.
---------------------------------------------------------------------------
by canni at 2012-01-11T10:15:46Z
👍
As this is new feature it cannot fit into 2.0 series, but 2.1 is just few clicks ahead, maybe this feature will fit into ;)
---------------------------------------------------------------------------
by bschussek at 2012-01-31T08:23:05Z
ping @fabpot
👍
---------------------------------------------------------------------------
by stof at 2012-01-31T08:51:26Z
@mlively could you rebase your branch ? it conflicts with the current master
---------------------------------------------------------------------------
by mlively at 2012-01-31T21:38:39Z
Yes, I can do that might be later today.
Commits
-------
8dc78bd [Form] Fixed YODA issues
600cec7 [Form] Added missing entries to CHANGELOG and UPGRADE
b154f7c [Form] Fixed docblock and unneeded use statement
399af27 [Form] Implemented checks to assert that values and indices generated in choice lists match their requirements
5f6f75c [Form] Fixed outstanding issues mentioned in the PR
7c70976 [Form] Fixed text in UPGRADE file
c26b47a [Form] Made query parameter name generated by ORMQueryBuilderLoader unique
18f92cd [Form] Fixed double choice fixing
f533ef0 [Form] Added ChoiceView class for passing choice-related data to the view
d72900e [Form] Incorporated changes suggested in PR comments
28d2f6d Removed duplicated lines from UPGRADE file
e1fc5a5 [Form] Restricted form names to specific characters to (1) fix generation of HTML IDs and to (2) avoid problems with property paths.
87b16e7 [Form] Greatly improved ChoiceListInterface and all of its implementations
Discussion
----------
[Form] Improved ChoiceList implementation and made form naming more restrictive
Bug fix: yes
Feature addition: yes
Backwards compatibility break: **yes**
Symfony2 tests pass: yes
Fixes the following tickets: #2869, #3021, #1919, #3153
Todo: adapt documentation
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue1919)
The changes in this PR are primarily motivated by the fact that invalid form/field names lead to various problems.
1. When a name contains any characters that are not permitted in HTML "id" attributes, these are invalid
2. When a name contains periods ("."), form validation is broken, because they confuse the property path resolution
3. Since choices in expanded choice fields are directly translated to field names, choices applying to either 1. or 2. lead to problems. But choices should be unrestricted.
4. Unless a choice field is not expanded and does not allow multiple selection, it is not possible to use empty strings as choices, which might be desirable in some occasions.
The solution to these problems is to
* Restrict form names to disallow unpermitted characters (solves 1. and 2.)
* Generate integer indices to be stored in the HTML "id" and "name" attributes and map them to the choices (solves 3.). Can be reverted to the old behaviour by setting the option "index_generation" to ChoiceList::COPY_CHOICE
* Generate integer values to be stored in the HTML "value" attribute and map them to the choices (solves 4.). Can be reverted to the old behaviour by setting the option "value_generation" to ChoiceList::COPY_CHOICE
Apart from these fixes, it is now possible to write more flexible choice lists. One of these is `ObjectChoiceList`, which allows to use objects as choices and is bundled in the core. `EntityChoiceList` has been made an extension of this class.
$form = $this->createFormBuilder()
->add('object', 'choice', array(
'choice_list' => new ObjectChoiceList(
array($obj1, $obj2, $obj3, $obj4),
// property path determining the choice label (optional)
'name',
// preferred choices (optional)
array($obj2, $obj3),
// property path for object grouping (optional)
'category',
// property path for value generation (optional)
'id',
// property path for index generation (optional)
'id'
)
))
->getForm()
;
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-19T18:09:09Z
Rather than passing `choices` and a `choice_labels` arrays to the view would it make sense to introduce a `ChoiceView` class and pass one array of objects?
---------------------------------------------------------------------------
by stof at 2012-01-22T15:32:36Z
@bschussek can you update your PR according to the feedback (and rebase it as it conflicts according to github) ?
---------------------------------------------------------------------------
by bschussek at 2012-01-24T00:15:42Z
@kriswallsmith fixed
Fixed all outstanding issues. Would be glad if someone could review again, otherwise this PR is ready to merge.
---------------------------------------------------------------------------
by fabpot at 2012-01-25T15:17:59Z
Is it ready to be merged?
---------------------------------------------------------------------------
by Tobion at 2012-01-25T15:35:50Z
Yes I think so. He said it's ready to be merged when reviewed.
---------------------------------------------------------------------------
by bschussek at 2012-01-26T02:30:36Z
Yes.
---------------------------------------------------------------------------
by bschussek at 2012-01-28T12:39:00Z
Fixed outstanding issues. Ready for merge.
ad (1): HTML4 "id" attributes are limited to strings starting with a letter and containing only letters, digits, underscores, hyphens, periods and colons.
ad (2): Property paths contain three special characters needed for correct parsing: left/right bracket and period.
The rules for form naming are:
* Names may start with a letter, a digit or an underscore. Leading digits or underscores will be stripped from the "id" attributes.
* Names must only contain letters, digits, underscores, hyphens and colons.
* Root forms may have an empty name.
Solves #1919 and #3021 on a wider scope.
BC Break: no
Feature addition: yes
Symfony2 tests pass: yes
Fixes the following issues: #2790
Todo: need more testing
This PR enables usage of empty string as a form name (only at root level).
With implementations of this interface, existing types can be amended.
The Csrf extension, for example, now contains a class FormTypeCsrfExtension
that adds CSRF capabilities to the "form" type.
To register new type extensions in the DIC, tag them with "form.type_extension"
and the name of the extended type as alias.
The extension classes are now the only constructor argument of the FormFactory class. They replace the existing "type loader" classes.
new FormFactory(array(
new CoreExtension($validator, $storage),
new CsrfExtension($csrfProvider),
new DoctrineOrmExtension($em),
));
Together with a few upcoming commits this mechanism will make
* extension of the form framework in bundles and
* usage of the forms outside of Symfony2
much easier.
Moving the template context creation makes sense and allows for simpler code for the end user:
Before:
return array('post' => $post, 'form' => $this->get('form.factory')->createTemplateContext($form));
After:
return array('post' => $post, 'form' => $form->getContext());
You can now modify set or bound data by adding a filter for either of the following events:
* Filters::filterBoundDataFromClient
* Filters::filterBoundData
* Filters::filterSetData
Instead, hidden fields now override the "row" template to not include a label or errors.
The "rest" (former "hidden") helper has been adapted to output any fields that were not
rendered manually. It should usually be called at the end of a form.
Fields are not available in the templates anymore. Instead, all required information can be
accessed through view variables.
Example usage of helpers and variables in a form theme:
// use the label helper
{{ this.label('my label') }}
// use the label variable
{{ this.vars.label }}
{{ label }}
Example usage of helpers and variables in a normal template:
// use the label helper
{{ field.label('my label') }}
// use the label variable
{{ field.vars.label }}
The implication is that set<Reference>() in the object of the parent form will not be called (and thus not has to be implemented/public).
If you want to suppress this behaviour, manually set "by_reference" to false.
Separated validation of data and form had serious drawbacks. When a form had nested form whose data was not connected to the data of the root form, this data would not be validated.
The new implementation validates the whole object graph at once. Class Form has a new method validateData(), that manually passes the data to the GraphWalker of the Validator and overrides the Default group with the groups set in the form.