Commits
-------
f9a486e [Validator] Added support for pluralization of the SizeLengthValidator
c0715f1 [FrameworkBundle], [TwigBundle] added support for form error message pluralization
7a6376e [Form] added support for error message pluralization
345981f [Validator] added support for plural messages
Discussion
----------
[Validator] Added support for plural error messages
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Todo: create translations for en and update others (FrameworkBundle)
[](http://travis-ci.org/hason/symfony)
---------------------------------------------------------------------------
by fabpot at 2011-05-14T20:41:01Z
@bschussek: What's your opinion?
---------------------------------------------------------------------------
by stof at 2011-09-04T13:14:29Z
@hason could you rebase your branch on top of master and update the PR ?
You also need to change the messages in the constraint that uses the pluralization to a pluralized format.
---------------------------------------------------------------------------
by stof at 2011-10-16T18:06:22Z
@hason ping
---------------------------------------------------------------------------
by stof at 2011-11-11T14:58:19Z
@hason ping again
---------------------------------------------------------------------------
by stof at 2011-12-12T20:39:10Z
@hason ping again. Can you update your PR ?
---------------------------------------------------------------------------
by hason at 2011-12-12T21:29:14Z
@stof I hope that I will update PR this week.
---------------------------------------------------------------------------
by bschussek at 2012-01-15T19:07:32Z
Looks good to me.
---------------------------------------------------------------------------
by canni at 2012-02-02T17:28:54Z
@hason can you update this PR and squash commits, it conflicts with current master
---------------------------------------------------------------------------
by hason at 2012-02-09T07:21:41Z
@stof, @canni Rebased.
What is the best solution for the translation of messages?
1. Change messages in the classes and all xliff files?
2. Keep messages in the classes and change all xliff files?
---------------------------------------------------------------------------
by stof at 2012-02-09T08:19:41Z
The constraints contain the en message so you will need to modify them to update the message
---------------------------------------------------------------------------
by hason at 2012-02-09T08:55:55Z
I prefer second option. The Validator component should be decoupled from the Translation component. The constraints contain the en message which is also the key for Translation component. We should create validators.en.xlf in the FrameworkBundle for en message. I think that this is better solution. What do you think?
---------------------------------------------------------------------------
by stof at 2012-04-04T02:22:02Z
@hason Please rebase your branch. It conflicts with master because of the move of the tests
@fabpot ping
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)
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This is cleanup after enabling empty form names, now form with empty name
will not render the default `id="form"` container attribute.
Developers can extend/override this behaviour by standard form theming methods.
* 2.0:
[Form] fixed previous merge
[Form] simplified previous merge
Also identify FirePHP by the X-FirePHP-Version header
[TwigBundle] Extract output buffer cleaning to method
[TwigBundle] Do not clean output buffering below initial level
Fixed rendering of FileType (value is not a valid attribute for input[type=file])
Added tests for string fix in DateTimeToArrayTransformer (8351a11286).
Added check for array fields to be integers in reverseTransform method. This prevents checkdate from getting strings as arguments and throwing incorrect ErrorException when submitting form with malformed (string) data in, for example, Date field. #2609
[Translation] removed unneeded methods
[Translation] added detection for circular references when adding a fallback catalogue
[DomCrawler] trim URI in getURI
[Yaml][Tests] Fixed missing locale string for Windows platforms which caused test to fail
This commit also fixes exception pages when Twig is not enabled as a templating engine.
Instead of just displaying the raw Twig template as before, we now fallback to the default
exception handler introduced some time ago.
Commits
-------
aeaf44a Removed unused code from DateTimeType
3c2539f Throw exception when "date_widget" option is not equal to "time_widget"
305c476 Overwrite child options ("widget", "empty_value") if any given
7bc19f9 Added to `DateTimeType` extension possibility to render form as `single_text` (similar to `DateType` option) (issue #1323 it requires fix for #1205)
17b41b2 Added to `TimeType` extension possibility to render form as `single_text` (similar to DateType option) (issue #1205) Adjusted `DateTimeType` to allow usage of this new feature
Discussion
----------
[Form][DateTimeType] Added "widget" and "empty_value" options
Hey,
I have just added "widget" and "empty_value" options to `DateTimeType`:
* `widget` option will overwrite existing `date_widget` and `time_widget`,
* `empty_value` behave exacly same way as it does for `ChoiceType`, `DateType` and `TimeType`
Also added and `FormException` when `date_widget` is not equal to `time_widget`, now is throwed non intuitive one (this will be changed in next days to allow different values for this options).
Closes#1323
Commits
-------
2cf7136 [FrameworkBundle][Form] tweak the choice widget PHP template
Discussion
----------
[FrameworkBundle][Form] tweak the choice widget PHP template
* make theming easier,
* factorize code,
* make PHP similar to Twig (easier to maintain)
Commits
-------
4e3406d Sync with master and clean up
ad5d2c1 Added to `TimeType` extension possibility to render form as `single_text` (similar to DateType option) (issue #1205) Adjusted `DateTimeType` to allow usage of this new feature
Discussion
----------
[Form][TimeType] Added possibility to render form as "single_text"
Added to `TimeType` extension possibility to render form as `single_text` (similar to `DateType` option) (issue #1205)
Adjusted `DateTimeType` to allow usage of this new feature
---------------------------------------------------------------------------
by ouardisoft at 2011/06/17 03:41:18 -0700
+1
---------------------------------------------------------------------------
by stloyd at 2011/06/21 01:05:51 -0700
@fabpot Any decision about this one ? I'm asking because I also have similar fix for #1323 but it requires this one ;-)
---------------------------------------------------------------------------
by fabpot at 2011/06/22 23:32:08 -0700
@stloyd: Can you rebase to master?
---------------------------------------------------------------------------
by stloyd at 2011/06/23 05:03:44 -0700
@fabpot Done.
Rules are as follows:
* If multiple is true, then the empty_value is ignored
* If not, and if the field is not required, the empty_value is set to the empty string by default and displayed
* If the field is required, and if the user explicitely set the empty_value, then it is displayed
* kriswallsmith/form/collection-proto:
added script[type="text/html"] collection prototype to form themes
[Form] removed collection prototype from form tree
The current implementation is not ready for inclusion in 2.0. It has several
known problems (security, not possible to disable it, not "cloud-compatible",
...) and it's not a must have feature anyway.
Some references:
* Security issue in FileType: https://github.com/symfony/symfony/issues/1001
* Validation fails on file, still stored in TemporaryStorage: https://github.com/symfony/symfony/issues/908
* Add a size argument & ability to configure TemporaryStorage: https://github.com/symfony/symfony/pull/748
This feature should be reworked and discussed for inclusion in 2.1.
If you use the MinLength validator with your entities, the ValidatorTypeGuesser gets the value, stored as "minlength". Then, the FormFactory generates a "pattern" attribute out of minlength and maxlength.
Modern browsers such as Chrome use this attribute to validate the form before submitting.
a "pattern" attribute is generated that validates the
The form component should now guarantee to always pass an UploadedFile object to your model. There you can call getOriginalName() to retrieve the original name of the uploaded file. For security reasons, the real file name is a generated hash value.
The consequence of this commit is that variables are accessible that have been passed to a surrounding form helper.
Example template:
{% block my_widget_label %}
<label>{{ label }}
{% endblock %}
{% block my_widget_row %}
{# It is not necessary to explicitely pass through the label variable #}
{{ form_label(form) }}
{{ form_widget(form) }}
{% endblock %}
Example usage:
{{ form_row(form.mywidget, { 'label': 'My Widget' }) }}
[Form] Fixed {get,set,has}Var references in templating php
[Form] Added getVars to FormView to ease usage in Twig. Also added some phpdoc and cleaned up the get method by adding a default value
[Form] Fix
[Form] Delete file generated by test
This addresses the potential issue where a user doesn't realize that there are multiple exception messages because the
full stack trace of the first exception is displayed (pushing the others far far down the page). This hides the stacktrace
of all exceptions (when there are more than one) by default, making each exception message easily viewable.
Controllers:
"BlogBundle:Post:show" is now "Blog:Post:show"
Templates:
"BlogBundle:Post:show.html.twig" is now "Blog:Post:show.html.twig"
Resources:
"@BlogBundle/Resources/config/blog.xml" is now "@Blog/Resources/config/blog.xml"
Doctrine:
"$em->find('BlogBundle:Post', $id)" is now "$em->find('Blog:Post', $id)"
The background is that Chrome only displays the content returned on an error page if payload is at least 512 bytes.
Prior to this change, the 404 page was just a few bytes short, resulting in the Chrome error message instead of the
real one returned by Symfony (confusing for the user).
Before
bundle:section:template.format.renderer
After
bundle:section:template.renderer.format
Notice that both the renderer and the format are mandatory.
