[Validator] Rename constraint Size to Range
[Validator] Rename constraint CollectionSize to Size
[Validator] Merge the SizeLength into the Size constraint
[Validator] Update messages in Size constraint for consistancy
[Validator] Add english and french translation for Size messages
[Validator] Tweak expected types for exceptions in SizeValidator
[Validator] Fix CS in SizeValidator
[Validator] Update the ValidatorTypeGuesser
[Validator] Tweak SizeValidator
[Validator] Update CHANGELOG
[Validator] Complete previous CHANGELOG updates
[Form] Update validator type guesser
[Validator] Pluralize collection size english messages
[Validator] Pluralize Size french messages
Commits
-------
498b814 [FrameworkBundle] minor fix in TranslationUpdateCommand <info> was not properly closed.
Discussion
----------
[FrameworkBundle] TranslationUpdateCommand <info> was not properly closed.
---------------------------------------------------------------------------
by travisbot at 2012-05-13T13:43:06Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1319869) (merged 498b8140 into e1934527).
---------------------------------------------------------------------------
by fabpot at 2012-05-13T17:06:25Z
Can you reopen a PR on the 2.0 branch as this is a bug fix? Thanks.
---------------------------------------------------------------------------
by stof at 2012-05-13T18:09:39Z
@fabpot this command is a 2.1 feature (even if it was added 6 month ago and so seems already old). There is nothing to fix in 2.0
Since the redesign of the Web-Debug-Toolbar, a new PHP icon has been
set, but its color was a bit darker (#000000) than the other icons in
the toolbar (#302e32 for the Symfony2 logo). This commit aims to ajust
the background color of the PHP logo to keep a certain homogeneity.
Commits
-------
709be4b [WDT] added documentation link
Discussion
----------
[WDT] added documentation link
This adds a documentation link in the WDT for the appropriate branch according to the current symfony version.
@weaverryan there is no documentation branch yet for the currently created 2.1 branch.
Also it might be a nice feature to redirect the dev branch to master automatically on the website. I.e. `http://symfony.com/doc/2.1/index.html` -> `http://symfony.com/doc/master/index.html`
@fabpot It might be a good idea to introduce a `Kernel::BRANCH` constant. So there would be no need to extract the branch from the symfony version in `ConfigDataCollector`. And bumping new versions/branches would be in one place.
---------------------------------------------------------------------------
by vicb at 2012-04-27T14:17:07Z
Maybe the documentation server should redirect to the right version according to `Kernel::VERSION` (i.e. using rewritting) ?
---------------------------------------------------------------------------
by Tobion at 2012-04-27T14:31:49Z
That would be best yes.
---------------------------------------------------------------------------
by fabpot at 2012-05-10T06:03:45Z
FYI, I've added some more constants about the Symfony version: 48099a852c (modeled after PHP constants)
---------------------------------------------------------------------------
by fabpot at 2012-05-10T07:08:57Z
I've just updated the website to accept any `HttpKernel::VERSION` string. Some redirection examples:
* 2.0.12 -> current
* 2.0 -> current
* 2.0.12-DEV -> current
* 2.1 -> master
* 2.1.0-DEV -> master
---------------------------------------------------------------------------
by Tobion at 2012-05-10T12:49:16Z
👍 for updating the website. But I think you missed to return 404 for a non-existent main doc page.
http://symfony.com/doc/2.4/book/controller.html -> 404 as expected
http://symfony.com/doc/2.4/index.html -> does not return 404 (and all links there are dead)
---------------------------------------------------------------------------
by travisbot at 2012-05-10T15:12:07Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1296057) (merged 04adf361 into a01dec00).
---------------------------------------------------------------------------
by fabpot at 2012-05-10T17:21:06Z
I've fixed the doc index for non-existing versions. Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by Tobion at 2012-05-10T22:49:18Z
done
---------------------------------------------------------------------------
by travisbot at 2012-05-10T22:52:13Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1300414) (merged 709be4b7 into fae4523f).
Commits
-------
1e84f1e [TwigBundle] implemented context auto-escaping in Twig templates based on the template extension
Discussion
----------
[2.2] Implements context escaping for Twig (fixes#839)
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Currently the ports in RetryAuthenticationEntryPoint are fixed in the constructor call, there is no way to set them when you run your application on different ports.
With this fix the ports are taken from the router configuration.
Commits
-------
246c885 [Form] Fixed: Default value of 'error_bubbling' is now determined by the 'single_control' option
d3bb4d0 [Form] Renamed option 'primitive' to 'single_control'
167e64f [Form] Fixed: Field attributes are not rendered in the label anymore. Label attributes are now passed in "label_attr"
68018a1 [Form] Dropped useless test that is guaranteed by OptionsParser tests and that needs to be adapted very often
649752c [Form] Fixed: CSRF token was not displayed on empty complex forms
c623fcf [Form] Fixed: CSRF protection did not run if token was missing
eb75ab1 [Form] Fixed results of the FieldType+FormType merge.
Discussion
----------
[Form] Fixed errors introduced in the FieldType+FormType merge
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3994, #4000, #2294, #4118
Todo: -
---------------------------------------------------------------------------
by Tobion at 2012-04-22T15:39:20Z
`primitive` is a pretty abstract option name. It depends on the person what he considers primitive. Maybe more explicit naming or better documentation what it means.
---------------------------------------------------------------------------
by bschussek at 2012-04-22T15:47:29Z
Better suggestions?
The distinction here is between primitive and complex forms, where primitive forms are such forms that can be represented by a single HTML tag. This obviously needs to be documented.
---------------------------------------------------------------------------
by Tobion at 2012-04-22T15:49:45Z
Maybe `single_widget` or something like that.
---------------------------------------------------------------------------
by vicb at 2012-04-23T13:09:43Z
@Tobion @bschussek would `elementary` be better than `primitive` ?
---------------------------------------------------------------------------
by vicb at 2012-04-23T13:17:04Z
and `compound \ composite` better than `complex` ?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T14:08:33Z
@vicb I fail to see how elementary/compound is easier to understand than primitive/complex. Maybe single_widget, but what's the opposite of this case? multi_widget?
---------------------------------------------------------------------------
by vicb at 2012-04-23T14:15:09Z
Actually I am fine with anything... as long as it is documented.
---------------------------------------------------------------------------
by bschussek at 2012-04-23T14:22:31Z
Still I think that this unveals a more profound naming problem. How do we (also in the documentation) name forms with children (formerly "forms") and forms without children (formerly "fields")?
Should we refer to them as
* forms and fields?
* complex and primitive forms?
* ...
We must first answer this question before we can find an intuitive option name. If the documentation always switches between different terminologies, neither will it be understandable nor will this option be easy to remember.
---------------------------------------------------------------------------
by vicb at 2012-04-23T15:10:32Z
> Still I think that this unveals a more profound naming problem. How do we (also in the documentation) name forms with children (formerly "forms") and forms without children (formerly "fields")?
To make it clear, I would rather say forms that **can have** children and forms that **can not have** children (i.e. Empty collections have no children but they can have and this is reason why you have to introduce those options, right ? - that could be a good example for the doc).
It will probably be better to refer to "complex" / "primitive" forms in the doc (and use the "form" / "field" terms to explain them).
Note: I think @Tobion concern is that "primitive" / "complex" could be pejorative terms (this is why I have proposed "elementary" / "compound").
---------------------------------------------------------------------------
by Tobion at 2012-04-23T16:00:54Z
1. primitive/complex is subjective (and could be pejorative too)
2. elementary/compound is more explicit so probably better than primitive/complex
3. I dislike this option in general. Does it make sense to change this option from a user perspective? I guess it's always the same as long as the widget structure stays the same. So it should be resolved at a higher level dynamically from the widget structure and not exposed to any configuration.
4. In documentation I would use the terms forms and fields. Because all people with HTML knowledge will understand that fields cannot have sub-fields whereas forms can. But since this distinction is not findable in code, it should be mentioned that all these are implemented as a form hierarchy.
---------------------------------------------------------------------------
by mvrhov at 2012-04-23T16:02:00Z
how about simple and complex?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T16:06:33Z
@Tobion It does not make sense to change this option from the user perspective, still the overloading type has to propagate to FormType whether it is a form or a field, so that the default behaviour is correct.
A second option how to implement this is to add a method `isField` to FormTypeInterface that can be overloaded and receives the options. I don't really like to introduce new methods here unless absolutely required.
What about renaming the option "primitive" to "is_field"? The blocks in the template would then be named "form_widget_field" and "form_widget_form".
---------------------------------------------------------------------------
by tristanbes at 2012-04-25T14:01:06Z
Oh, I should've seen this before, i thought I was doing something wrong. (empty collections gets an input field bug)
Please big :UP: on this. When will it be merged ? @bschussek
---------------------------------------------------------------------------
by Tobion at 2012-04-25T15:30:28Z
+1 for "is_field" and "form_widget_field" but I would rather use "form_widget_compound" instead of "form_widget_form" which is quite strange.
---------------------------------------------------------------------------
by bschussek at 2012-04-26T16:34:04Z
@Tobion "simple" and "compound" then?
---------------------------------------------------------------------------
by Tobion at 2012-04-26T16:49:58Z
no "field" and "compound"
---------------------------------------------------------------------------
by bschussek at 2012-04-26T17:17:02Z
I don't like "field" for a simple reason: Consider the "date" type. We are typically speaking of the "date" field there. But technically, the "date" field is a compound field. So?
---------------------------------------------------------------------------
by Tobion at 2012-04-26T21:17:37Z
I don't understand the open question. You proposed "is_field" and "form_widget_field" yourself. So calling the template block "form_widget_field" is a comprehensible consequence of "is_field". I wouldn't call the date type with multiple inputs a field.
---------------------------------------------------------------------------
by tristanbes at 2012-04-26T21:52:39Z
We should take a decision cause right here i got all my forms that are broken because of the empty collection rendering as input field :-).
I guess we are many in that situation.
---------------------------------------------------------------------------
by bschussek at 2012-04-27T08:28:16Z
I renamed "primitive" to "single_control" now to match with the HTML specification which names all input elements (input, select etc.) "controls". The opposite is now "compound".
Meanwhile, I added a fix for #4118.
@fabpot This is ready for merge now.
---------------------------------------------------------------------------
by Tobion at 2012-04-27T10:22:49Z
Hm, I know naming things is hard and sometimes not really important. But since users need to know which block to override, it is essential to make it clear. I think there is still one issue.
The block is named `form_widget_single_control` in order, as you said, to abstract away if it's an input, select etc. But in fact it can only render `input` and nothing else. So this is misleading.
So you could also simply name it `form_widget_input`.
Apart from that I agree with everything.
English:
The value is not a country.
Danish translation in the latest commit:
Denne værdi er ikke et land.
Danish translation in the first commit and mine version:
Værdien er ikke et land
So this commit is simply to make the danish translation the same, and
not two different expressions..
Commits
-------
e344609 [DependencyInjection] Fixed composer.json
1aa0786 [FrameworkBundle] Fixed composer.json
3601f61 [DoctrineBridge] Fixed composer.json
Discussion
----------
Fix composer json
---------------------------------------------------------------------------
by jalliot at 2012-04-22T14:22:24Z
`suggest` no longer requires a version constraint. While you're at it, maybe you could change those to more meaningful strings explaining what each optional dependency provides.
---------------------------------------------------------------------------
by willdurand at 2012-04-22T14:24:27Z
I know, but the version is fine. It's more up to @fabpot to add description in each `suggest` entries.
Anyway, this is not the purpose of this PR. If you want to contribute on that, feel free :)
Commits
-------
ffc074b [Profiler] Fixed IE7 JavaScript errors
Discussion
----------
[Profiler] Fixed IE7 JavaScript errors
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Requires merge of another [PR](https://github.com/doctrine/DoctrineBundle/pull/61) available on the `doctrine/DoctrineBundle` repository (compatibility changes to `db.html.twig`).
---------------------------------------------------------------------------
by fabpot at 2012-04-20T14:15:22Z
That does not work for me.
