Commits
-------
1474aa5 [Form] Fixed consideration of Twig's template inheritance and added another performance-improving check
b4ec7f5 Fixed my rubbish English
d11f8b5 [Form] Fixed passing of variables in the FormRenderer
629093e [Form] Extracted common parts of FormHelper and FormExtension into separate classes
216c539 [Form] Implemented a more intelligent caching strategy in FormHelper (PHP +100ms, Twig +100ms)
Discussion
----------
[Form] Merged FormHelper and FormExtension and implemented a better caching strategy
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR extracts common parts of `FormHelper` and `FormExtension` into implementations of the new interfaces `FormRendererInterface` and `FormRendererEngineInterface`. The implemented `AbstractRendererEngine` features a more intelligent caching strategy than the one used before. When this strategy was implemented directly in `FormHelper`, the performance of [this specific, heavy form](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1) could be improved from **2.5** to **2.25 seconds** on my machine for PHP templates.
Due to the abstraction and delegation, the performance gain is not that big anymore, but we still have a performance gain of about **0.1 seconds** for both PHP and Twig in the above example. The second, big improvement of this PR is maintainability - the differences between PHP and Twig templates are now contained in relatively small classes - and extendability (it is very easy now to support different template engines).
---------------------------------------------------------------------------
by stof at 2012-07-14T13:47:19Z
should a similar refactoring be done for the [Twig rendering](https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Extension/FormExtension.php) ?
---------------------------------------------------------------------------
by bschussek at 2012-07-14T13:49:25Z
Yes. I would like to merge the common parts of Twig's FormExtension and PHP's FormHelper into an abstract class. Before that I need to have a [working, heavy Twig Form](https://twitter.com/webmozart/status/224135287377371138) in order to measure whether I don't actually decrease the performance with Twig. Can you help me there?
---------------------------------------------------------------------------
by vicb at 2012-07-16T21:48:24Z
Would it make sense to create a 'renderer' folder in the form component and move related classes there ?
---------------------------------------------------------------------------
by stof at 2012-07-16T22:06:58Z
@vicb It makes sense to keep the Twig renderer in the brisge. This is what the bridge is about. Moving the Twig class to the component would not be consistent. And the PHP renderer is already in the component (but it could make sense to move the helper from FrameworkBundle to the TemplatingExtension of the Form component though)
---------------------------------------------------------------------------
by vicb at 2012-07-16T22:16:50Z
@stof I was only referring to the classes located in the Component/Form folder.
---------------------------------------------------------------------------
by vicb at 2012-07-16T22:27:27Z
Overall I don't really know what to think of this PR. PHP and Twig use a different way to support blocks:
- PHP has one block per file,
- Twig could have many blocks per templates.
I am not sure if this PR is optimal for Twig and improves maintainability ?
---------------------------------------------------------------------------
by stof at 2012-07-16T22:46:11Z
@vicb it avoids duplicating the whole rendering logic for each engine (there is at least a third one in [SmartyBundle](https://github.com/noiselabs/SmartyBundle/blob/master/Extension/FormExtension.php) btw)
---------------------------------------------------------------------------
by bschussek at 2012-07-17T07:16:42Z
@vicb I don't think a renderer subfolder makes sense. The interfaces belong to the main namespace, and then the subfolder would only contain two classes.
Considering maintainability for Twig, I think that this PR in fact increases it. TwigExtension before always had to check the whole type hierarchy, while now the code in AbstractRendererEngine makes sure that this process is speeded up.
Before:
```
load _some_entity_field_label:
- check _some_entity_field_label
- check entity_label
- check choice_label
- check form_label
load _some_other_entity_field_label
- check _some_other_entity_field_label
- check entity_label
- check choice_label
- check form_label
a.s.o.
```
After:
```
load _some_entity_field_label:
- check _some_entity_field_label
- check entity_label (hits the cache if entity_label was checked before)
- check choice_label (hits the cache if choice_label was checked before)
- check form_label
load _some_other_entity_field_label
- check _some_other_entity_field_label
- check entity_label (now definitely hits the cache)
a.s.o.
```
Since many fields share the same ancestors in the inheritance tree, this definitely improves performance.
As can also be deducted here, custom block names such as `_some_entity_field_label` are now a major drawback. There is nothing we can cache for them, so they need to be checked for every individual block that we load. Removing this feature surprisingly gains no performance for Twig (I need to investigate why at some point), but it speeds up rendering for **250ms** using the PHP engine on [this example form](advancedform.gpserver.dk/app_dev.php/taxclasses/1), dropping the rendering time from 1.25 to 1 sec on my local machine. I'm not sure what we should do here.
---------------------------------------------------------------------------
by stof at 2012-07-17T07:21:31Z
@bschussek could it be possible to have an implementation checking the custom block and another one skipping it ? This way, the user could disable this feature when he does not need it.
---------------------------------------------------------------------------
by bschussek at 2012-07-17T07:38:34Z
@stof It would be possible to add a switch to `FormRenderer` that controls whether custom blocks are checked or not.
If this switch is disabled by default, we break BC. If this switch is enabled by default, it will be pretty useless. People will start designing away for custom blocks, and once they want to improve performance, they can't turn off the switch anymore because it would require too many changes.
---------------------------------------------------------------------------
by stof at 2012-07-17T08:08:38Z
@fabpot what do you think about it ?
---------------------------------------------------------------------------
by bschussek at 2012-07-17T08:41:43Z
Another option that just came to mind is to remove inheritance checks for anything but _widget and _row. I.e., if we render `entity_widget`, check
```
_id_widget
entity_widget
choice_widget
form_widget
```
But if we render `entity_label`, only check
```
_id_label
form_label
```
This improves PHP Templating for **170ms** and Twig for **20ms**. We gain another **150ms** for PHP Templating and **~15ms** for Twig if we also restrict custom fields (_id_widget) to the _widget and _row suffixes (it's really hard to tweak the renderer for Twig.. I think a lot of its performance bottlenecks lie in Twig itself).
Do you have any data on how often blocks other than _widget and _row are customized for specific types/IDs?
---------------------------------------------------------------------------
by stof at 2012-07-17T09:47:38Z
Well, I think most of the time other blocks are not even customized based on the type :)
---------------------------------------------------------------------------
by Tobion at 2012-07-17T14:32:39Z
From my experience rendering the form components individually is easier and more flexible than customizing by ID or type.
But there are still use cases for customizing like library-like bundles (e.g. Bootstrap).
Commits
-------
23d8735 Added NativeFileSessionHandler to classes to compile .
12d6ae7 Removed FileSessionHandler from FrameworkExtension to stop compiling a file that does not exist.
Discussion
----------
[FrameworkBundle] Removed FileSessionHandler from FrameworkExtension to stop compiling a file that does not exist.
PR #4899 removed FileSessionHandler which caused a class not found error from FrameworkBundle after the cache was created. This PR will fix it.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Todo: -
License of the code: MIT
---------------------------------------------------------------------------
by stof at 2012-07-13T19:12:51Z
you should add the NativeSessionHandler class in the list instead as it replaces it
---------------------------------------------------------------------------
by tystr at 2012-07-13T19:14:29Z
+1
---------------------------------------------------------------------------
by zachbadgett at 2012-07-13T19:15:55Z
Done
Commits
-------
cd7835d [Form] Cached the form type hierarchy in order to improve performance
2ca753b [Form] Fixed choice list hashing in DoctrineType
2bf4d6c [Form] Fixed FormFactory not to set "data" option if not explicitely given
7149d26 [Form] Removed invalid PHPDoc text
Discussion
----------
[Form] WIP Improved performance of form building
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: **Update the Silex extension**
This PR is work in progress and up for discussion. It increases the performance of FormFactory::createForm() on a specific, heavy-weight form from **0.848** to **0.580** seconds.
Before, the FormFactory had to traverse the hierarchy and calculate the default options of each FormType everytime a form was created of that type.
Now, FormTypes are wrapped within instances of a new class `ResolvedFormType`, which caches the parent type, the type's extensions and its default options.
The updated responsibilities: `FormFactory` is a registry and proxy for `ResolvedFormType` objects, `FormType` specifies how a form can be built on a specific layer of the type hierarchy (e.g. "form", or "date", etc.) and `ResolvedFormType` *does the actual building* across all layers of the hierarchy (by delegating to the parent type, which delegates to its parent type etc.).
---------------------------------------------------------------------------
by schmittjoh at 2012-07-12T18:25:40Z
Maybe ResolvedFormType
---------------------------------------------------------------------------
by jmather at 2012-07-13T02:56:38Z
I really like ResolvedFormType. That's the naming method I took for my tag parser that handes the same conceptual issue.
---------------------------------------------------------------------------
by axelarge at 2012-07-13T05:25:00Z
ResolvedFormType sounds very clear.
This change is great and I desperately hope to see more of this kind
---------------------------------------------------------------------------
by Baachi at 2012-07-13T06:41:26Z
Yes `ResolvedFormType` sounds good :) 👍
---------------------------------------------------------------------------
by fabpot at 2012-07-13T07:11:33Z
I like `ResolvedFormType` as well.
---------------------------------------------------------------------------
by henrikbjorn at 2012-07-13T07:46:48Z
👍 `ResolvedFormType` :shipit:
---------------------------------------------------------------------------
by stof at 2012-07-13T18:01:51Z
This looks good to me
Commits
-------
c061c30 Router#resolveString should return null instead of empty string when $value is null
a1d1a02 Null default value route regression
Discussion
----------
[Router] Null default value route regression
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4823
Todo:
License of the code: MIT
Documentation PR:
---
The commit by @vicb 0555913fbb introduces a regression in the handling of default values that are null, while there are requirements still set for this value.
This is a failing test case and fix for the issue.
---------------------------------------------------------------------------
by merk at 2012-07-10T04:24:40Z
Now contains a fix, tests now pass.
Commits
-------
0555913 [FrameworkBundle] Allow using kernel parameters in routes
Discussion
----------
[FrameworkBundle] Allow using kernel parameters in routes
Kernel parameters can now be used at any position in patterns, defaults and requirements.
Relates to: #3316, #3276
**Differences from 3316:**
- The substitution is now done in the `Router`,
- 3316 uses `$container->getParameterBag()` which is not part of the `ContainerInterface`. The way it been solved in this PR is that some code have been duplicated inside the `Router`, see `resolveString()`.
**BC break:**
Before this PR, nonexistent parameters would have be silently ignored (ie `%idontexist%` would not have been replaced). After this PR, they will throw an exception. However you can escape the value (ie `%%idontexist%%` will be accepted and replaced by `%idontexist%`).
_This behavior is not mandatory and can be reverted if needed. However this keeps the router more consistent with the DI_.
Any feedback ? @helmer @Koc
---------------------------------------------------------------------------
by Seldaek at 2012-07-04T12:40:08Z
👍 for consistency.
---------------------------------------------------------------------------
by helmer at 2012-07-04T13:07:11Z
+1 a much better solution to the problem than mine, closing #3316
---------------------------------------------------------------------------
by Tobion at 2012-07-04T13:21:59Z
How about escaping kernel params with `\%idontexist%` as I suggested it for route params in 4563?
---------------------------------------------------------------------------
by stof at 2012-07-04T13:28:55Z
@Tobion this would not be consistent with the way DI parameters are escaped elsewhere
---------------------------------------------------------------------------
by Koc at 2012-07-04T14:24:25Z
Looks good for me, thanx.
The charset was configurable in a configuration file but it never worked:
framework:
charset: ISO-8859-1
Now, like for the cache and log dirs, you can configure the charset by
overriding the getCharset() method in the app kernel:
public function getCharset()
{
return 'ISO-8859-1';
}
Commits
-------
f09789b [FrameworkBundle] Generate the class cache when warming up the cache
Discussion
----------
[FrameworkBundle] Generate the class cache when warming up the cache
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/jalliot/symfony.png?branch=load-class-cache)](http://travis-ci.org/jalliot/symfony)
Fixes the following tickets: -
Todo: -
With this PR, the commands `cache:clear` (if `--no-warmup` hasn't been specified) and `cache:warmup` generate the class cache. Now the first page load after clearing the cache does not take over one second anymore :)
Of course, if someone does not want to use the class cache for whatever reason, he can always remove the `$kernel->loadClassCache()` in his front controller and the cache will just be ignored...
On a side note, can someone explain why [SensioDistributionBundle does not warmup the cache in the Composer post-install script](https://github.com/sensio/SensioDistributionBundle/blob/master/Composer/ScriptHandler.php#L48)?
---------------------------------------------------------------------------
by travisbot at 2012-06-10T05:18:30Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1579114) (merged baecbaee into 6266b72d).
---------------------------------------------------------------------------
by travisbot at 2012-06-10T05:24:48Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1579154) (merged f09789b1 into 6266b72d).
---------------------------------------------------------------------------
by jalliot at 2012-06-28T23:18:54Z
@fabpot ping
Commits
-------
7464dcd added phpdoc
c413e7b [Routing] remove RequestContextAwareInterface from RequestMatcherInterface
921be34 [Routing] fix phpdoc
Discussion
----------
[Routing] RequestMatcherInterface doesn't need context
Matchers that implement RequestMatcherInterface should match a Request, thus they don't need the request context.
---------------------------------------------------------------------------
by travisbot at 2012-06-14T21:39:48Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1624496) (merged f5ff1fe0 into 7c91ee57).
---------------------------------------------------------------------------
by schmittjoh at 2012-06-15T13:32:59Z
I think it makes sense to remove the RequestContext from the RequestMatcher.
---------------------------------------------------------------------------
by travisbot at 2012-06-15T15:54:28Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1628931) (merged 7464dcd2 into f881d282).
---------------------------------------------------------------------------
by Tobion at 2012-06-26T12:32:06Z
Anything missing?
Commits
-------
c1e4166 moved create of default form label to view layer
Discussion
----------
move create of default form label to view layer
A small optimization if you provide custom labels in the view layer (i.e. `{{ form_label(form.name, 'Your name') }}`
```
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
```
---------------------------------------------------------------------------
by travisbot at 2012-06-24T14:45:17Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1694310) (merged 37f0b774 into 0d4b02e4).
---------------------------------------------------------------------------
by travisbot at 2012-06-24T15:03:44Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1694418) (merged c1e4166e into 0d4b02e4).
Commits
-------
eb26e89 [FrameworkBundle] Fix built-in server when using query params in paths
Discussion
----------
[FrameworkBundle] Fix built-in server when using query params in paths
$_SERVER['REQUEST_URI'] will contain the query params so is_file will fail.
I propose to use $_SERVER['SCRIPT_FILENAME'] instead which contains the full path and no query params.
---------------------------------------------------------------------------
by ajessu at 2012-06-23T10:17:34Z
I was going to make this comment on your approach in #4484, but I'll make it here, since that issue is already closed.
Your solution won't work on PHP 5.4.0, as `$_SERVER['SCRIPT_FILENAME']` will not be set [see PHP bug #60850](https://bugs.php.net/bug.php?id=60850).
Also PHP 5.4.1 and up, if you don't request a file explicitely, Ex:
http://localhost:8000/app_dev.php
but a location, Ex:
http://localhost:8000/
The value of the `$_SERVER['SCRIPT_FILENAME']` will be the router file, not the script name, which makes relying on `$_SERVER['SCRIPT_FILENAME']` inconsistent. [See this comment on the php bug](https://bugs.php.net/bug.php?id=60850#1331261652)
I'm not sure if (nor how?) the issue of the params should be addressed on this "default" router, to not make it overly complex.
For your use case, and this is just my own early opinion without much thought, in case we can't come up with a general solution, there is always the option of defining your own router and passing it to the `server:run` command with `--router` like so:
php app/console server:run --router=app/config/my_own_router.php
---------------------------------------------------------------------------
by flojon at 2012-06-23T10:31:47Z
So would `$_SERVER['SCRIPT_NAME']` be more reliable? Like this:
if (is_file($_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . $_SERVER['SCRIPT_NAME'])) {
return false;
}
I did a simple test and `$_SERVER['SCRIPT_NAME']` is set to `/` when accessing the root (using PHP 5.4.3).
---------------------------------------------------------------------------
by flojon at 2012-06-23T10:51:22Z
Browse around the code a bit and `$_SERVER['SCRIPT_NAME']` has been there since PHP 5.4.0:
https://github.com/php/php-src/blob/php-5.4.0/sapi/cli/php_cli_server.c#L598
---------------------------------------------------------------------------
by travisbot at 2012-06-23T11:16:59Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1688361) (merged eb26e896 into 0d4b02e4).
---------------------------------------------------------------------------
by travisbot at 2012-06-24T10:23:52Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1688043) (merged 71855665 into 0d4b02e4).
---------------------------------------------------------------------------
by CHH at 2012-06-29T07:17:32Z
This works fine for me!
👍
Could someone please merge this? This issue makes the `server:run` command currently quite unusable, because it can't load CSS for example which has a `?v=` parameter.
---------------------------------------------------------------------------
by ajessu at 2012-06-29T08:25:14Z
👍 from me also. Works just like `$_SERVER['REQUEST_URI']`, but doesn't include the params.
Tested working on PHP 5.4.0 and 5.4.3.
Commits
-------
8ae0fa2 [FrameworkBundle] Fixed locale detection from request
Discussion
----------
[FrameworkBundle] Fixed locale detection from request
---------------------------------------------------------------------------
by travisbot at 2012-06-25T10:09:24Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1699743) (merged 8ae0fa21 into 03c8d4d2).
Commits
-------
ab47a88 [FrameworkBundle][Translator] Fix test for request being available in order to get the locale.
Discussion
----------
[FrameworkBundle][Translator] Fix test for request being available.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3472
Todo: -
$_SERVER['REQUEST_URI'] will contain the query params so is_file will fail.
Change it to use $_SERVER['SCRIPT_NAME'] instead which only contains the
relative filename of the the script.
Commits
-------
31843cf [FrameworkBundle] Add info to config
d5ab4c1 [Routing] Update changelog
bbef65e [Routing] Add strict_parameters option to disable exceptions when a route generation fails due to an invalid parameter
Discussion
----------
[Routing] Add strict_parameters option to disable exceptions on invalid parameters
---------------------------------------------------------------------------
by travisbot at 2012-06-09T15:07:26Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1577025) (merged bbef65e6 into 37678e17).
---------------------------------------------------------------------------
by stof at 2012-06-09T15:43:48Z
Seems good, but you forgot to update the Changelog of the component. Anyway, let's wait for @vicb's review as he knows the Routing component better than me.
---------------------------------------------------------------------------
by Seldaek at 2012-06-09T16:35:56Z
I updated the changelog
---------------------------------------------------------------------------
by travisbot at 2012-06-09T16:38:31Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1577716) (merged d5ab4c1d into 37678e17).
---------------------------------------------------------------------------
by travisbot at 2012-06-11T10:10:37Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1590901) (merged a54e59e4 into 37678e17).
---------------------------------------------------------------------------
by travisbot at 2012-06-11T13:50:21Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1591926) (merged 31843cf0 into 0995b1f2).
Commits
-------
3c8cc0a [HttpFoundation][Sessions] Refactored tests
13a2c82 [FrameworkBundle] Refactor session file handler service name and update changelogs
b2cc580 [HttpFoundation] Removed Native*Handler session save handler classes
f33b77c [HttpFoundation] Added a custom file save handler
Discussion
----------
[HttpFoundation][Sessions] Removed native save handlers
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
Added a specific filesessionhandler
Removed native handlers to slim down code.
---------------------------------------------------------------------------
by travisbot at 2012-05-30T02:54:40Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1473181) (merged 3c8cc0a1 into adf07f1e).
Commits
-------
23bb668 [FrameworkBundle][SecurityBundle] updated configuration to new method names
8775f2c [Config] replaced setInfo(), setExample() with more generic attributes
Discussion
----------
[Config] replaced setInfo(), setExample() with more generic attributes
This replaces ``setInfo`` and ``setExample`` with a more generic attribute system which provides more flexibility and is more future prove.
I have kept the specialized ``setInfo`` and ``setExample`` methods because they are a bit shorter, and also a good demonstration of what the system could be used for. However for consistency, I have renamed them to ``info()`` and ``example()`` respectively.
---------------------------------------------------------------------------
by travisbot at 2012-05-26T17:37:06Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1442720) (merged 8775f2c1 into 9e951991).
---------------------------------------------------------------------------
by stof at 2012-05-26T17:42:02Z
and you forgot to update FrameworkBundle
---------------------------------------------------------------------------
by travisbot at 2012-05-26T17:46:37Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1442764) (merged 23bb668e into 9e951991).
Commits
-------
64101ab separate numeric value from suffix in File constraint's error message `$uploadIniSizeErrorMessage`
ff122d3 fixed tests
868d649 separate numeric values from suffixes in File constraint's error message `$maxSizeMessage`
Discussion
----------
[Validator] separate numeric values from suffixes in File validation error messages
This change allows me to locale-aware format the numbers in a form theme, i.e., to use a comma instead of a dot. If there's a better way without re-implementing the entire validator, let me know.
Such changes also allow for using a different separator than the usual space in translations.
---------------------------------------------------------------------------
by travisbot at 2012-05-08T19:14:16Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1278845) (merged f7c50098 into e54f4e46).
---------------------------------------------------------------------------
by travisbot at 2012-05-08T19:23:31Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1278940) (merged ce1cdafc into e54f4e46).
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-05-10T11:05:18Z
I don't know if there is a better way to do this, but I like the idea anyway.
---------------------------------------------------------------------------
by craue at 2012-05-11T14:18:52Z
Separated numeric values and suffixes for `$maxSizeMessage` and `$uploadIniSizeErrorMessage` now. Can't find any other relevant places (in other validators). Might be merged if accepted.
---------------------------------------------------------------------------
by travisbot at 2012-05-11T14:19:10Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1305246) (merged 438da7dd into e54f4e46).
---------------------------------------------------------------------------
by travisbot at 2012-05-11T21:22:25Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1309277) (merged 64101aba into dd0da03c).
---------------------------------------------------------------------------
by sstok at 2012-05-13T13:29:07Z
Using the NumberFormatter class would be an option, but that would also add a dependency when using Validation as stand-alone so using the {{ suffix }} is a good idea.
---------------------------------------------------------------------------
by craue at 2012-05-13T14:15:54Z
Using a NumberFormatter (if available) directly in the validator might indeed be a good option. In either case, having the numeric value separated from its suffix looks cleaner.
---------------------------------------------------------------------------
by craue at 2012-05-19T13:36:00Z
@fabpot: Would you merge this?
Commits
-------
bc7043f [Routing] removed unused constructor arguments in test classes
d81fdfe [Routing] fixed namespace of test classes
53aaf76 [Routing] removed unused property of Router
Discussion
----------
[Routing] removed unused property of Router
Test pass: yes
BC break: no
This PR removes an unused property ($defaults) of Router. The property was passed to the constructor of UrlMatcher and UrlGenerator although these classes don't accept this parameter at all. And the dumped equivalents of them (produced by PhpMatcherDumper/PhpGeneratorDumper) don't need this property either.
So passing the $defaults was wrong and the property is not used in any way.
The DI config does not define anything for this property either: [routing.xml](https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Resources/config/routing.xml#L52)
The second commit fixes the namespaces of test classes that were wrong.
The third commit removes false arguments in the test classes.
---------------------------------------------------------------------------
by travisbot at 2012-05-22T07:34:03Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1397749) (merged bc7043f1 into e4e3ce6c).
Commits
-------
3a5e84f [Validator] Add CollectionSize constraint
Discussion
----------
[Validator] Add CollectionSize constraint
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
I will also send a PR to the documentation as soon as this one is accepted.
---------------------------------------------------------------------------
by bschussek at 2012-04-29T08:24:28Z
-1
I dislike the rising amount of very specific constraints in the core. Can't we add this to Size?
---------------------------------------------------------------------------
by vicb at 2012-04-29T09:01:39Z
@bschussek #3918 implements what you propose but then the messages are not valid any more:
```php
<?php
public $minMessage = 'This value should be {{ limit }} or more';
public $maxMessage = 'This value should be {{ limit }} or less';
public $invalidMessage = 'This value should be a valid number';
```
I can imagine 2 solutions:
- adding some more message,
- rename the `Size` constraint to `Range` and create a new `Size` constraint for arrays / countables.
What do you think ?
---------------------------------------------------------------------------
by bschussek at 2012-04-29T09:27:53Z
I'd prefer the second solution and merge `Size` with `SizeLength` as well.
---------------------------------------------------------------------------
by vicb at 2012-04-29T09:34:50Z
@bschussek It would make sense. @makasim @Herzult any one of you would like to contribute this (i.e. rename the current Size to Range and create a new Size supporting arrays / countables / strings) ?
---------------------------------------------------------------------------
by Herzult at 2012-04-29T14:31:12Z
Yep, I'm on it.
---------------------------------------------------------------------------
by stof at 2012-04-29T15:22:44Z
@Herzult could you take the other comment into account and merge SizeLength into you Size ?
---------------------------------------------------------------------------
by vicb at 2012-04-29T15:33:05Z
The guessers should also be modified (it might also affect the ODM which is in an other repo, if so it would be good to sync the changes).
---------------------------------------------------------------------------
by Herzult at 2012-04-29T16:38:19Z
@stof the problem merging SizeLength into Size is that they don't have the same required options & messages.
---------------------------------------------------------------------------
by Herzult at 2012-04-29T16:47:40Z
And what about renaming Range to Interval and SizeLength to IntervalLength?
---------------------------------------------------------------------------
by stof at 2012-04-29T16:54:38Z
Well, SizeLength is about matching the length of a string currently. Nothing related to intervals
---------------------------------------------------------------------------
by Herzult at 2012-04-29T17:29:40Z
Here are the current names:
* **Size** for collection (countable) size
* **Range** for numbers
* **SizeLength** for strings
Merging **SizeLength** into **Size** is maybe not appropriate because collections and strings are different things. It'll be hard to find messages that fit both collections and strings. Maybe we had better to find a better name for both. What do you think?
About the ValidatorTypeGuesser, I'll update it as soon as we know ow to name the constraints.
---------------------------------------------------------------------------
by vicb at 2012-04-29T17:43:01Z
Size is a good name for both strings and "collections", could we have two sets of strings and select according to the type ?
---------------------------------------------------------------------------
by Herzult at 2012-04-29T22:39:55Z
I tried to merge them together, what do you think?
---------------------------------------------------------------------------
by vicb at 2012-04-30T06:52:37Z
I think your changes are great, may be @bschussek has more feedback. The ValidatorTypeGuesser and the translation are yet to be updated.
---------------------------------------------------------------------------
by hhamon at 2012-05-01T12:32:28Z
Am I missing something or `SizeLength` for strings is a duplicate for `MinLength` and `MaxLength` constraints?
---------------------------------------------------------------------------
by Herzult at 2012-05-02T13:29:36Z
Yep, that's true. But the only link between this PR and the SizeLength constraint is that I merged it to the one I introduced.
---------------------------------------------------------------------------
by Herzult at 2012-05-07T07:48:01Z
@bschussek what do you think?
---------------------------------------------------------------------------
by vicb at 2012-05-10T19:51:26Z
@Herzult this PR looks good to me, could you update the changelog and update guides, try to factorize the code and squash the commits ? Thanks.
---------------------------------------------------------------------------
by travisbot at 2012-05-11T15:42:35Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1306112) (merged 8d8e6443 into 4ac3bddb).
---------------------------------------------------------------------------
by vicb at 2012-05-11T21:42:21Z
* could #4259 be helpful ?
* please squash the commits.
* please create a PR / issue on [symfony-docs](https://github.com/symfony/symfony-docs)
thanks for the updates.
---------------------------------------------------------------------------
by travisbot at 2012-05-13T18:38:18Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1321123) (merged eeda9044 into 4ac3bddb).
---------------------------------------------------------------------------
by travisbot at 2012-05-13T18:45:12Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1321146) (merged 491ca19a into 8b54eb56).
---------------------------------------------------------------------------
by travisbot at 2012-05-14T11:29:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1326110) (merged 44865024 into 8b54eb56).
---------------------------------------------------------------------------
by vicb at 2012-05-14T11:49:37Z
@Herzult what about plural translations ?
---------------------------------------------------------------------------
by travisbot at 2012-05-14T16:52:37Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328677) (merged 93480f95 into 46ffbd52).
---------------------------------------------------------------------------
by travisbot at 2012-05-14T17:03:13Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328705) (merged 326c3b81 into 46ffbd52).
---------------------------------------------------------------------------
by vicb at 2012-05-14T20:19:18Z
thanks for the updates, this PR looks fine to me. @bschussek ?
---------------------------------------------------------------------------
by vicb at 2012-05-16T06:45:51Z
@Herzult can you squash your commits ?
---------------------------------------------------------------------------
by travisbot at 2012-05-16T11:20:44Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1344811) (merged 3a5e84f4 into 58b6ef23).
[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
-------
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: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3994)
---------------------------------------------------------------------------
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.