Here is the code you need to write when using the regular render
function for an ESI strategy:
{{ render(path('path'), { strategy: 'esi' })
}}
And the same with the new render_* function:
{{ render_esi(path('path')) }}
This PR was merged into the master branch.
Commits
-------
6703fb5 added changelog entries
1997e2e fix phpdoc of UrlGeneratorInterface that missed some exceptions and improve language of exception message
f0415ed [Routing] made reference type fully BC and improved phpdoc considerably
7db07d9 [Routing] added tests for generating relative paths and network paths
75f59eb [Routing] add support for path-relative and scheme-relative URL generation
Discussion
----------
[2.2] [Routing] add support for path-relative URL generation
Tests pass: yes
Feature addition: yes
BC break: <del>tiny (see below)</del> NO
deprecations: NO
At the moment the Routing component only supports absolute and domain-relative URLs, e.g.
`http://example.org/user-slug/article-slug/comments` and
`/user-slug/article-slug/comments`.
But there are two link types missing: schema-relative URLs and path-relative URLs.
schema-relative: e.g. `//example.org/user-slug/article-slug/comments`
path-relative: e.g. `comments`.
Both of them would now be possible with this PR. I think it closes a huge gap in the Routing component.
Use cases are pretty common. Schema-relative URLs are for example used when you want to include assets (scripts, images etc) in a secured website with HTTPS. Path-relative URLs are the only option when you want to generate static files (e.g. documentation) that can be downloaded as an HTML archive. Such use-cases are currently not possible with symfony.
The calculation of the relative path based on the request path and target path is hightly unit tested. So it is really equivalent. I found several implemenations on the internet but none of them worked in all cases. Mine is pretty short and works.
I also added an optional parameter to the twig `path` function, so this feature can also be used in twig templates.
Ref: This implements path-relative URLs as suggested in #3908.
<del>[BC BREAK] The signature of UrlGeneratorInterface::generate changed to support scheme-relative and path-relative URLs. The core UrlGenerator is BC and does not break anything, but users who implemented their own UrlGenerator need to be aware of this change. See UrlGenerator::convertReferenceType.</del>
---------------------------------------------------------------------------
by jalliot at 2012-04-16T09:56:56Z
@Tobion For completeness, you should add the option to the `url` and `asset` twig functions/template helpers.
---------------------------------------------------------------------------
by stof at 2012-04-16T10:46:06Z
@jalliot adding the option to ``url`` does not make any sense. The difference between ``path`` and ``url`` is that ``path`` generates a path and ``url`` generates an absolute url (thus including the scheme and the hostname)
---------------------------------------------------------------------------
by Tobion at 2012-04-16T12:27:49Z
@stof I guess jalliot meant we could then generate scheme-relative URLs with `url`. Otherwise this would have no equivalent in twig.
---------------------------------------------------------------------------
by jalliot at 2012-04-16T12:34:08Z
@stof Yep I meant what @Tobion said :)
---------------------------------------------------------------------------
by Tobion at 2012-04-18T11:57:04Z
The $relative parameter I added besides the existing $absolute parameter of the `->generate` method was not clear enough. So I merged those into a different parameter `referenceType`. I adjusted all parts of symfony to use the new signature. And also made the default `UrlGenerator` implementation BC with the old style. So almost nobody will recognize a change. The only BC break would be for somebody who implemented his own `UrlGenerator` and did not call the parent default generator.
Using `referenceType` instead of a simple Boolean is much more flexible. It will for example allow a custom generator to support a new reference type like http://en.wikipedia.org/wiki/CURIE
---------------------------------------------------------------------------
by Tobion at 2012-04-18T13:34:58Z
ping @schmittjoh considering your https://github.com/schmittjoh/JMSI18nRoutingBundle/blob/master/Router/I18nRouter.php would need a tiny change
---------------------------------------------------------------------------
by schmittjoh at 2012-04-18T13:37:39Z
Can you elaborate the necessary change?
---------------------------------------------------------------------------
by Tobion at 2012-04-18T13:51:10Z
This PR changes the signature of `generate` to be able to generate path-relative and scheme-relative URLs. So it needs to be
`public function generate($name, $parameters = array(), $referenceType = self::ABSOLUTE_PATH)` and your implementation would need to change `if ($absolute && $this->hostMap) {` to `if (self::ABSOLUTE_URL === $referenceType && $this->hostMap) {`
I can do a PR if this gets merged.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-18T13:52:14Z
If I understand correctly, the old parameter still works, no?
edit: Ah, ok I see what you mean now.
---------------------------------------------------------------------------
by Tobion at 2012-04-18T13:56:33Z
Yeah the old parameter still works but $absolute would also evaluate to true (a string) in your case for non-absolute URLs, i.e. paths.
---------------------------------------------------------------------------
by Tobion at 2012-04-19T21:09:46Z
ping @fabpot
---------------------------------------------------------------------------
by fabpot at 2012-04-20T04:30:18Z
Let's discuss that feature for 2.2.
---------------------------------------------------------------------------
by Tobion at 2012-04-20T10:40:59Z
What are your objections against it? It's already implemented, it works and it adds support for things that are part of a web standard. The BC break is tiny at the moment (almost nobody is affected) because the core UrlGenerator works as before. But if we waited for 2.2 it will be much harder to make the transition because 2.1 is LTS. So I think is makes sense to add it now. Furthermore it makes it much more future-proof as custom generators can more easiliy add support for other link types like CURIE. At the moment a Boolean for absolute URLs is simply too limited and also somehow inconsistent because $absolute = false stands for an absolute path. You see the awkwardness in this naming.
Btw, I added a note in the changelog. And I will add documentation of this feature in symfony-docs once this is merged.
---------------------------------------------------------------------------
by fabpot at 2012-04-20T12:14:32Z
nobody has ever said that 2.1 would be LTS. Actually, I think we are going to wait for 2.3 for LTS.
---------------------------------------------------------------------------
by Tobion at 2012-04-20T12:27:18Z
Well what I meant is, the longer we wait with this, the harder to apply it.
In 04ac1fdba2 you modified `generate` signature for better extensibility that is not even made use of. I think changing `$abolute` param goes in the same direction and has direct use.
I'd like to know your reason to wait for 2.2. Not enough time to review it, or afraid of breaking something, or marketing for 2.2?
---------------------------------------------------------------------------
by stof at 2012-04-20T16:28:27Z
@Tobion the issue is that merging new features forces to postpone the release so that it is tested by enough devs first to be sure there is no blocking bug in it. Big changes cannot be merged when we are hunting the remaining bugs to be able to release.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-20T16:42:11Z
Considering the changes that have been made to the Form component, and are still being made, I think this is in comparison to that a fairly minor change.
Maybe a clearer guideline on the release process, or the direction would help, and avoid confusion, or wrong expectations on contributors' part.
---------------------------------------------------------------------------
by Tobion at 2012-10-05T13:52:11Z
@fabpot this is ready. So if you agree with it, I would create a documentation PR.
---------------------------------------------------------------------------
by stof at 2012-10-13T16:09:47Z
@fabpot what do you think about this PR ?
---------------------------------------------------------------------------
by Crell at 2012-11-01T16:05:01Z
This feels like it's overloading the generate() method to do double duty: One, make a URl based on a route. Two, make a URI based on a URI snippet. Those are two separate operations. Why not just add a second method that does the second operation and avoid the conditionals? (We're likely to do that in Drupal for our own generator as well.)
---------------------------------------------------------------------------
by Tobion at 2012-11-01T16:38:39Z
@crell: No, you must have misunderstood something. The generate method still only generates a URI based on a route. The returned URI reference can now also be a relative path and a network path. Thats all.
---------------------------------------------------------------------------
by Tobion at 2012-12-13T18:30:28Z
@fabpot this is ready. It is fully BC! I also improved phpdoc considerably.
---------------------------------------------------------------------------
by Tobion at 2012-12-14T20:51:38Z
@fabpot Do you want me to write documentation for it? I would also be interested to write about the new features of the routing component in general. I wanted to do that anyway and it would probably be a good fit for your "new in symfony" articles.
---------------------------------------------------------------------------
by fabpot at 2012-12-14T20:58:16Z
Im' going to review this PR in the next coming days. And to answer your second question, more documentation or better documentation is always a good thing, so go for it.
---------------------------------------------------------------------------
by Tobion at 2013-01-02T21:50:20Z
@fabpot ping. I added changelog entries.
This PR was merged into the master branch.
Commits
-------
586a16e [Validator] Changed DefaultTranslator::getLocale() to always return 'en'
58bfd60 [Validator] Improved the inline documentation of DefaultTranslator
cd662cc [Validator] Added ExceptionInterface, BadMethodCallException and InvalidArgumentException
e00e5ec [Validator] Fixed failing test
cc0df0a [Validator] Changed validator to support pluralized messages by default
56d61eb [Form][Validator] Added BC breaks in unstable code to the CHANGELOG
1e34e91 [Form] Added upgrade instructions to the UPGRADE file
b94a256 [DoctrineBridge] Adapted DoctrineBridge to translator integration in the validator
c96a051 [FrameworkBundle] Adapted FrameworkBundle to translator integration in the validator
92a3b27 [TwigBridge] Adapted TwigBridge to translator integration in the validator
e7eb5b0 [Form] Adapted Form component to translator integration in the validator
46f751c [Validator] Extracted message interpolation logic of ConstraintViolation and used the Translation component for that
Discussion
----------
[Validator] Integrated the Translator in the Validator component
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #5844, #6117
Todo: -
License of the code: MIT
Documentation PR: -
This PR allows to replace the default message substitution strategy in the validator (`strtr()`) by passing an implementation of `Symfony\Component\Translation\TranslatorInterface`. The motivation for this are both #5844 and the need to replace the translation strategy in Drupal's integration of the Validator.
In the stand-alone usage of the validator, both the translator and the default translation domain can now be passed to `ValidatorBuilderInterface`:
```php
$validator = Validation::createValidatorBuilder()
->setTranslator(new MyTranslator())
->setTranslationDomain('validators')
->getValidator();
```
References:
* #5844
* #6117
* #6129
* [Add a validation framework to Drupal 8](http://drupal.org/node/1845546)
* [Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3.](http://drupal.org/node/1849564)
---------------------------------------------------------------------------
by Tobion at 2012-11-28T08:53:25Z
no BC break? Looking at ValidatorBuilderInterface there is definitely one.
---------------------------------------------------------------------------
by bschussek at 2012-11-28T08:55:01Z
ValidatorBuilderInterface is not part of the stable API. You are not supposed to implement this interface.
---------------------------------------------------------------------------
by Tobion at 2012-11-28T09:01:07Z
We're not only documenting bc breaks for stable API, otherwise we could remove 90% of the upgrade file since few methods are tagged with API.
An interface that nobody should implement?
---------------------------------------------------------------------------
by bschussek at 2012-11-28T09:30:02Z
The question is what to consider a BC break. Something will always break for someone. Should we consequently mark everything as BC break? I don't think so.
For example, since 2.1, you are supposed to use `Validation::createValidator*()` for creating a validator. Because of that, I won't consider changing the constructor signature of `Validator` a BC break anymore from 2.1 on.
The same for the unstable interfaces. These are currently meant to be used only, that is, type hint against them and call their methods. But we don't guarantee that we won't add methods to them.
---------------------------------------------------------------------------
by Tobion at 2012-11-28T09:38:19Z
I agree that almost any change could be considered a BC break. So we probably need to better define what a BC break is and what not. Otherwise Symfony will stop evolving after 2.3 because from then on Fabien wanted to prevent BC breaks which is almost impossible in a strict definition of bc break.
---------------------------------------------------------------------------
by fabpot at 2012-11-28T11:37:22Z
BC breaks should always be documented, and we guarantee BC only for things tagged with @api. I'm going to update the docs to make things clearer.
---------------------------------------------------------------------------
by bschussek at 2012-11-28T13:09:57Z
@fabpot I documented these changes now in the CHANGELOG: af99ebb1206ac92889b7193ba1ecc12bf2617e85
Are we sure we want to document *all* BC breaks from now on, even in non-@api code? This could rather scare people looking at our changelogs (lots of BC BREAKS there).
---------------------------------------------------------------------------
by fago at 2012-11-28T17:29:58Z
Unfortunately, it turns out the symfony translator interface does not mach the Drupal translation system as well as we initally thought, see http://drupal.org/node/1852106. Given that, this would integrating the validator component into Drupal even harder, because it introduces the dependency on the (unwanted) translation component. :(
---------------------------------------------------------------------------
by stof at 2012-11-28T18:19:36Z
If this does not help Drupal anyway, maybe #5844 is a better way to manage translations for people using the validator outside forms ?
and the Drupal guys would simply follow a similar approach, but based on their own translator instead of the symfony one.
---------------------------------------------------------------------------
by fago at 2012-11-28T18:50:12Z
Yeah. The only problem I see with the approach of #5844 is that *after* validation only the translated messages are available. We'd need to have access to the untranslated messages also.
---------------------------------------------------------------------------
by fago at 2012-11-29T09:49:47Z
As our translation system handles translating pluralized messages differently, the current ExecutionContextInterface::addViolation() method poses a problem also. We need to pass on - both the single and plural - message, as the message gets chosen during translation, see http://api.drupal.org/api/drupal/core!includes!common.inc/function/format_plural/8
So maybe, we could allow adding an already created ConstraintViolation object also? Then, we could implement a "PluralConstraintViolation" class that takes both message templates.
---------------------------------------------------------------------------
by bschussek at 2012-12-03T15:52:36Z
I updated this PR to support pluralized messages by default in the validator. This should solve the problem of the Drupal guys, because their implementation of `TranslatorInterface::transChoice($id, $number, ...)` can now simply split the $id by pipes (`|`) and pass the parts to their own `format_plural($count, $singular, $plural, ...)` function.
For us, it breaks BC because translation catalog sources had to be adapted.
---------------------------------------------------------------------------
by fabpot at 2012-12-03T16:25:52Z
Most of the XLF files are broken (the end is missing now).
IIUC, we now have a hard dependency on the Translation component, which is something we wanted to avoid.
---------------------------------------------------------------------------
by fabpot at 2012-12-03T16:27:56Z
Oops, clicked on the "comment" button too fast.
So, the dependency is hard (you need to install the dep) but light as we only rely on the translation interface from the component (when using the default translator). It looks acceptable to me, especially because we now use Composer to manage dependencies.
---------------------------------------------------------------------------
by bschussek at 2012-12-03T16:54:10Z
@fabpot Thanks for the hint. Going to fix this.
---------------------------------------------------------------------------
by bschussek at 2012-12-04T11:34:43Z
@fabpot Fixed.
---------------------------------------------------------------------------
by bschussek at 2012-12-07T12:40:24Z
Is there anything missing for this PR to be merged?
* 2.1:
[Console] Fix style escaping parsing
[Console] Make style formatter matching less greedy to avoid having to escape when not needed
[Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
[Component] [Security] fixed PSR-2 coding violation in ClassUtilsTest class.
[Form] Fixed EntityChoiceList when loading objects with negative integer IDs
[TwigBundle] There is no CSS visibility of display, should be visible instead
[Form] corrected source node for a Danish translation
[DependencyInjection] fixed a bug where the strict flag on references were lost (closes#6607)
[HttpFoundation] Check if required shell functions for `FileBinaryMimeTypeGuesser` are not disabled
[CssSelector] added css selector with empty string
[HttpFoundation] Docblock for Request::isXmlHttpRequest() now points to Wikipedia
[DependencyInjection] refactored code to avoid logic duplication
[Form] Deleted references in FormBuilder::getFormConfig() to improve performance
[HttpFoundation] Update docblock for non-working method
Conflicts:
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/trace.html.twig
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/traces.html.twig
This PR was merged into the master branch.
Commits
-------
184c8e5 Fixed @expectedException definitions to reference absolute exception paths
Discussion
----------
Added leading slashes to @expectedException definitions
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: -
This PR adds leading backslashes `\` to `@expectedException` declarations.
The current version is inconsistent with other class references in doc blocks, which default to *relative* class names unless class name has a leading backslash.
```php
/**
* @param RelativeNs\Class $param1
* @param \AbsoluteNs\Class $param2
*/
but
/**
* @expectedException AbsoluteNs\Class
*/
```
Consequently, PHPStorm does not understand the current statements and marks them as erroneous (and correctly so IMO, even though PHPUnit's interpretation is more relaxed).
* 2.1:
Restrict Monolog version to be in version <1.3
[Console] Make getTerminalWith & getTerminalHeight public
[DependencyInjection] fixed PhpDumper optimizations when an inlined service depends on the current one indirectly
[DependencyInjection] fixed PhpDumper when an inlined service definition has some properties
[DependencyInjection] added some tests for PhpDumper when the container is compiled
[DependencyInjection] fixed CS
[Process] Do not reset stdout/stderr pipes on Interrupted system call
[Locale] Adjust `StubIntlDateFormatter` to have new methods added in PHP 5.5
use the right RequestMatcherInterface
[Locale] Fix failing `StubIntlDateFormatter` tests in PHP 5.5
[Locale] Fix failing `StubIntlDateFormatter` in PHP 5.5
[Form] Fix failing `MonthChoiceList` in PHP 5.5
Update .travis.yml
Conflicts:
src/Symfony/Bridge/Monolog/composer.json
src/Symfony/Component/DependencyInjection/Tests/Fixtures/php/services9.php
* 2.0:
Restrict Monolog version to be in version <1.3
[Console] Make getTerminalWith & getTerminalHeight public
[DependencyInjection] fixed PhpDumper optimizations when an inlined service depends on the current one indirectly
[DependencyInjection] fixed PhpDumper when an inlined service definition has some properties
[DependencyInjection] added some tests for PhpDumper when the container is compiled
[DependencyInjection] fixed CS
[Locale] Adjust `StubIntlDateFormatter` to have new methods added in PHP 5.5
[Locale] Fix failing `StubIntlDateFormatter` tests in PHP 5.5
[Locale] Fix failing `StubIntlDateFormatter` in PHP 5.5
[Form] Fix failing `MonthChoiceList` in PHP 5.5
Update .travis.yml
Conflicts:
src/Symfony/Bridge/Monolog/composer.json
src/Symfony/Component/DependencyInjection/Tests/Fixtures/php/services9.php
src/Symfony/Component/Form/Extension/Core/ChoiceList/MonthChoiceList.php
tests/Symfony/Tests/Component/DependencyInjection/Fixtures/yaml/services9.yml
* 2.1: (24 commits)
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Form] Fixed inheritance of "error_bubbling" in RepeatedType
[Form] Fixed DateType when used with the intl extension disabled.
[HttpFoundation] fix return types and handling of zero in Response
[HttpFoundation] better fix for non-parseable Expires header date
Fixed missing plural message in portuguese validator
Fix Expires when the header is -1
[DoctrineBridge] Allowing memcache port to be 0 to support memcache unix domain sockets.
[Console] fixed unitialized properties (closes#5935)
[Process] Prevented test from failing when pcntl extension is not enabled.
Revert "[DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option"
[Form] Fixed failing tests for DateTimeToStringTransformer.
[Locale] Fixed the StubLocaleTest for ICU versions lower than 4.8.
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
[Form] Fixed test regression introduced in #6440
[Tests] Fix namespaces
Fixed php doc of GenericEvent::__construct
HttpUtils must handle RequestMatcher too
use preferred_choices in favor of preferred_query
...
Conflicts:
src/Symfony/Bridge/Propel1/Form/ChoiceList/ModelChoiceList.php
* 2.0:
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Console] fixed unitialized properties (closes#5935)
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
bumped Symfony version to 2.0.21-DEV
updated VERSION for 2.0.21
updated CHANGELOG for 2.0.21
Conflicts:
src/Symfony/Bundle/SwiftmailerBundle/LICENSE
src/Symfony/Component/Filesystem/LICENSE
src/Symfony/Component/HttpFoundation/Response.php
src/Symfony/Component/HttpKernel/Kernel.php
This PR was merged into the master branch.
Commits
-------
163564b [WebProfilerBundle] replaced yaml_dump by json_encode to make the Web Profiler independent from the YAML component
1c92307 [WebProfilerBundle] fixed exception panel when no exception is thrown
00e08be [WebProfilerBundle] replaced usage of the render tag by the render function (to decouple the bundle from TwigBundle)
0e2418c [TwigBundle] added the HttpKernel extension to the default Twig loaded extensions
f0d9be0 [TwigBridge] added an extension for the HttpKernel component
Discussion
----------
Added an HttpKernelExtension in Twig bridge and used it in the WebProfiler
The first commit introduces a new HttpKernelExtension in the Twig bridge that allows the rendering of a sub-request from a template (the code mostly comes from Silex, and will replace the code there at some point).
The name `render` is probably not the best one as it does not really tell you what it does (the same goes for the `render` tag we have in Symfony2 by the way).
Here is a list of possible names:
* `render()`
* `render_request()`
* `request()`
* `subrequest()`
* `include_request()`
I don't really like the last one, but it is (perhaps) consistent with the `include` tag/function in Twig.
This new `render()` function is also a first step towards replacing the `render` tag (with support for ESI, SSI, ...). But it won't happen before we refactor the way it's managed now (a lot of the code is in the FrameworkBundle right now and that prevents Silex or Drupal to reuse it).
The other commits make use of this new extension to make the Web Profiler truly independent from TwigBundle and FrameworkBundle.
This PR was merged into the master branch.
Commits
-------
6b10550 Merge branch 'master' of github.com:symfony/symfony into deprecationErrors
1d82112 [Form] Fix two cases where deprecated methods were being used
b8cdbdc [Form] Catch deprecation errors that are caused by BC code
ebcb432 [Form] [FrameworkBundle] catch deprecation errors in tests
c21b12e [Form] handle BC use of deprecated stuff in non-test-methods.
fc2be6d [Form] catch deprecated errors in tests
800a032 [Form] replace bindRequest() with bind(), as bindRequest is deprecated
d5b2638 [Form] Trigger errors for deprecated methods in Form Component
f3d6966 [Validator] Stop using deprecated methods
d57ad32 [Form] Catch deprecation errors when using deprecated methods/classes in tests
3241157 [Validator] Trigger errors for deprecations
1f9eb7f return value of handleError
b35de9e Handle errors using a custom error handler
f49704b trigger errors for deprecated methods in HttpFoundation component
Discussion
----------
trigger_error() for deprecations
See also #6173 and #6139.
Started triggering errors in the HttpFoundation component.
It seems as if most of the time the error is just duplicating the text in the @deprecation comment.
Any opinions on if duplicating the text is acceptable, or if fetching the comment text to output the error makes sense?
---------------------------------------------------------------------------
by Seldaek at 2012-12-04T13:39:42Z
IMO it's fine to just duplicate the `@deprecated` note in the message, since anyway this code is meant to be completely deleted, this duplication should not do much harm.
---------------------------------------------------------------------------
by fabpot at 2012-12-06T08:22:21Z
@colinfrei I've merged PR #6173. Do you have time to implement the `trigger_error()` call everywhere? Thanks.
---------------------------------------------------------------------------
by colinfrei at 2012-12-06T08:36:55Z
Yep I'll finish that, probably until the beginning of next week.
---------------------------------------------------------------------------
by bschussek at 2012-12-10T10:15:12Z
Thank you for working on this!
---------------------------------------------------------------------------
by fabpot at 2012-12-12T11:08:53Z
@colinfrei: Is this PR finished? Can I merge it?
---------------------------------------------------------------------------
by colinfrei at 2012-12-12T12:09:19Z
@fabpot not quite - I lost some work due to a computer crash over the weekend. The only thing open is fixing the tests for the Form Component and catching the cases where the Form Component intentionally uses deprecated stuff.
---------------------------------------------------------------------------
by colinfrei at 2012-12-15T07:32:28Z
@fabpot - finished adding trigger_errors and catching them in Tests and as needed.
Travis is failing, but that seems to be master being broken due to the Finder changes?
I changed a few cases where the code was using deprecated methods which wasn't necessary in my eyes, specifically 1d8211249b, 800a032f07, f3d696636a
This PR was merged into the master branch.
Commits
-------
d5426f0 [Form] Add tests to prove that label is not rendered when is marked as false
120547c [Form][TwigBridge] Don't set label attributes if is marked as not to be rendered [Form][FrameworkBundle] Add option to disable rendering of label for fields
36e4556 [Form] Option for not displaying a label by setting label to false. [Form] Fixed formatting & translation ..
Discussion
----------
[Form] Added option for not displaying a form-label by setting label to false
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Replaces: #5421
@fabpot @BenjaminBeck: I was just not sure what to do with "table based" forms, so I left `<td></td>` rendered when there is no label, because I'm not sure that we can hide it easily.
---------------------------------------------------------------------------
by XWB at 2012-12-11T09:30:14Z
👍
* 2.1:
fixed CS
fixed CS
[Security] fixed path info encoding (closes#6040, closes#5695)
[HttpFoundation] added some tests for the previous merge and removed dead code (closes#6037)
Improved Cache-Control header when no-cache is sent
removed unneeded comment
Fix to allow null values in labels array
fix date in changelog
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
Revert "merged branch gajdaw/finder_splfileinfo_fpassthu (PR #4751)" (closes#6224)
Fixed a typo
Fixed: HeaderBag::parseCacheControl() not parsing quoted zero correctly
[Form] Fix const inside an anonymous function
[Config] Loader::import must return imported data
[DoctrineBridge] Fixed caching in DoctrineType when "choices" or "preferred_choices" is passed
[Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
[HttpFoundation] fixed a small regression
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/Session/Storage/Handler/MongoDbSessionHandlerTest.php
* 2.1:
[HttpFoundation] changed UploadedFile::move() to use move_uploaded_file() when possible (closes#5878, closes#6185)
[HttpFoundation] added a check for the host header value
[DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option
[DoctrineBridge] Improved exception message
[DoctrineBridge] Fixed: Exception is thrown if the entity class is not known to Doctrine
Removed useless branch alias for dev-master in composer.json
Conflicts:
composer.json
src/Symfony/Bridge/Doctrine/composer.json
src/Symfony/Bridge/Monolog/composer.json
src/Symfony/Bridge/Propel1/composer.json
src/Symfony/Bridge/Swiftmailer/composer.json
src/Symfony/Bridge/Twig/composer.json
src/Symfony/Bundle/FrameworkBundle/composer.json
src/Symfony/Bundle/SecurityBundle/composer.json
src/Symfony/Bundle/TwigBundle/composer.json
src/Symfony/Bundle/WebProfilerBundle/composer.json
src/Symfony/Component/BrowserKit/composer.json
src/Symfony/Component/ClassLoader/composer.json
src/Symfony/Component/Config/composer.json
src/Symfony/Component/Console/composer.json
src/Symfony/Component/CssSelector/composer.json
src/Symfony/Component/DependencyInjection/composer.json
src/Symfony/Component/DomCrawler/composer.json
src/Symfony/Component/EventDispatcher/composer.json
src/Symfony/Component/Filesystem/composer.json
src/Symfony/Component/Finder/composer.json
src/Symfony/Component/Form/composer.json
src/Symfony/Component/HttpFoundation/composer.json
src/Symfony/Component/HttpKernel/composer.json
src/Symfony/Component/Locale/composer.json
src/Symfony/Component/OptionsResolver/composer.json
src/Symfony/Component/Process/composer.json
src/Symfony/Component/Routing/composer.json
src/Symfony/Component/Security/composer.json
src/Symfony/Component/Serializer/composer.json
src/Symfony/Component/Templating/composer.json
src/Symfony/Component/Translation/composer.json
src/Symfony/Component/Validator/composer.json
src/Symfony/Component/Yaml/composer.json
This PR was merged into the 2.1 branch.
Commits
-------
b604eb7 [DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option
db2ee54 [DoctrineBridge] Improved exception message
99321cb [DoctrineBridge] Fixed: Exception is thrown if the entity class is not known to Doctrine
Discussion
----------
[DoctrineBridge] fixed caching when EntityType is used with the "query_builder" option
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
* 2.1: (29 commits)
[DependencyInjection] fixed composer.json
[Validator] Fix typos in validators.ru.xlf
Edited some minor grammar and style errors in russian validation file
Updated Bulgarian translation
[Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
[Form] simplified a test from previous merge
Update src/Symfony/Component/Form/Extension/Core/Type/FileType.php
fixed CS
Xliff with other node than source or target are ignored
small fix of #5984 when the container param is not set
Filesystem Component mirror symlinked directory fix
[Process][Tests] fixed chainedCommandsOutput tests
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
info about session namespace
fix upgrade info about locale
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
...
This PR was merged into the master branch.
Commits
-------
1858b96 [Form] Adapted FormValidator to latest changes in the Validator
1f752e8 [DoctrineBridge] Adapted UniqueValidator to latest changes in the Validator
efe42cb [Validator] Refactored the GraphWalker into an implementation of the Visitor design pattern.
Discussion
----------
[Validator] Refactored the Validator for use in Drupal
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: TODO
Drupal wants to use the Symfony Validator component in their next version. I was talking to @fago recently about the changes that we'd need to make and implemented these changes in this PR. I don't want to rush this, but the deadline is tight, since Drupal feature freeze is on December 1st and @fago needs at least a couple of days to integrate the Validator into Drupal.
This PR introduces two significant changes:
* Interfaces were created for all classes that constitute the Validator's API. This is were the PR breaks BC, because `ConstraintValidatorInterface::initialize()` is now type hinted against `ExecutionContextInterface` instead of `ExecutionContext`.
* The graph walker was refactored into an implementation of the Visitor pattern. This way, the validator was decoupled from the structure of the metadata (class → properties and getter methods) and makes it possible to implement a different metadata structure, as is required by the Drupal Entity API.
As a consequence of the API change, custom validation code is now much easier to write, because `ValidatorInterface` and `ExecutionContextInterface` share the following set of methods:
```php
interface ValidatorInterface
{
public function validate($value, $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $groups = null);
public function getMetadataFor($value);
}
interface ExecutionContextInterface
{
public function validate($value, $subPath = '', $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $subPath = '', $groups = null);
public function getMetadataFor($value);
}
```
No more juggling with property paths, no more fiddling with the graph walker. Just call on the execution context what you'd call on the validator and you're done.
There are two controversial things to discuss and decide (cc @fabpot):
* I moved the `@api` tags of all implementations to the respective interfaces. Is this ok?
* I would like to deprecate `ValidatorInterface::getMetadataFactory()` (tagged as `@api`) in favor of the added `ValidatorInterface::getMetadataFor()`, which offers the exact same functionality, but with a different API and better encapsulation, which makes it easier to maintain for us. We can tag `getMetadataFor()` as `@api`, as I don't expect it to change. Can we do this or should we leave the old method in?
I would like to decide the major issues of this PR until **Sunday November 25th** in order to give @fago enough room for his implementation.
Let me hear your thoughts.
This PR was merged into the 2.0 branch.
Commits
-------
2d9a6fc Use Norm Data instead of Data
Discussion
----------
[Form] Use Norm Data instead of App Data
This listener is triggered when normalized data are binded.
We have to use $event->getForm()->getNormData() instead of $event->getForm()->getData().
I have made a new FormType having 'entity' as parent and having a NormTransformer. I encountered a problem in MergeCollectionListener when the request is binded.
My commit fix it.
* 2.1: (24 commits)
forced Travis to use source to workaround their not-up-to-date Composer on PHP 5.3.3
[Routing] removed irrelevant string cast in Route
Fixed typo
Make YamlFileLoader and XmlFileLoader file loading extensible
[HttpKernel] fix typo
Fixed singularization of "prices"
[Form] Removed an exception that prevented valid formats from being passed, e.g. "h" for the hour, "L" for the month etc.
[HttpKernel] fixed Client when using StreamedResponses (closes#5370)
fixed PDO session handler for Oracle (closes#5829)
[HttpFoundation] fixed PDO session handler for Oracle (closes#5829)
[Locale] removed a check that is done too early (and it is done twice anyways)
Update src/Symfony/Component/Validator/Resources/translations/validators.fa.xlf
Adding new localized strings for farsi validation.
[HttpFoundation] moved the HTTP protocol check from StreamedResponse to Response (closes#5937)
[Form] Fixed forms not to be marked invalid if their children are already marked invalid
[Form] Excluded some tests in NumberToLocalizedStringTransformerTest which fail on ICU 4.4, but work on ICU 4.8
added missing tests from previous merge
[Form] Fixed NumberToLocalizedStringTransformer to accept both comma and dot as decimal separator, if possible
Fix export-ignore on Windows
Show correct class name InputArgument in error message
...
Conflicts:
.travis.yml
src/Symfony/Component/Form/Extension/Core/DataTransformer/NumberToLocalizedStringTransformer.php
This PR was merged into the master branch.
Commits
-------
b27b749 made usage of Composer autoloader for subtree-split unit tests
Discussion
----------
made usage of Composer autoloader for subtree-split unit tests
This PR also normalizes the way components are tested.
---------------------------------------------------------------------------
by stof at 2012-11-09T23:14:22Z
👍
This PR was merged into the 2.1 branch.
Commits
-------
646a714 Fix export-ignore on Windows
Discussion
----------
Fix export-ignore on Windows
Rules:
Tests/ export-ignore
don't work on Windows. My proposition is:
/Tests export-ignore
* 2.0:
[Form] Fixed NumberToLocalizedStringTransformer to accept both comma and dot as decimal separator, if possible
Show correct class name InputArgument in error message
shows correct class name InputOption in error message
The exception message should say which field is not mapped
[HttpFoundation] Fix name sanitization after perfoming move
Add check to Store::unlock to ensure file exists
Conflicts:
src/Symfony/Bridge/Doctrine/Validator/Constraints/UniqueEntityValidator.php
src/Symfony/Component/HttpFoundation/File/UploadedFile.php
tests/Symfony/Tests/Component/Console/Input/InputArgumentTest.php
tests/Symfony/Tests/Component/Console/Input/InputOptionTest.php
tests/Symfony/Tests/Component/Form/Extension/Core/DataTransformer/NumberToLocalizedStringTransformerTest.php
tests/Symfony/Tests/Component/HttpFoundation/File/FileTest.php
tests/Symfony/Tests/Component/HttpKernel/HttpCache/StoreTest.php
* 2.1:
removed unused use statements
[Form] Adapted HTML5 format in DateTimeType as response to a closed ICU ticket
[2.1][HttpFoundation] Fixed Php doc in Request::get
bumped Symfony version to 2.1.4-DEV
updated VERSION for 2.1.3
update CONTRIBUTORS for 2.1.3
updated CHANGELOG for 2.1.3
merged branch jakzal/yamlDoubleQuotesDumperFix (PR #4320)
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
This PR was squashed before being merged into the master branch (closes#5032).
Commits
-------
afba15f [2.2] Translatable field type for Propel i18n columns
Discussion
----------
[2.2] Translatable field type for Propel i18n columns
A field type which allows to automatically generate the correct fields for propels i18n behavior.
Usage example:
$builder->add('pageI18ns', 'translatable_collection', array(
'i18n_class' => '\foo\barBundle\Model\PageI18n',
'languages' => array('de', 'fr'),
'label' => 'Translations',
'columns' => array(
'title' => array(
'label' => 'Custom title',
),
'description' => array(
'type' => 'textarea'
)
)
));
With this configuration the field automatically generates the correct fields for the title and description column for the given languages.
---------------------------------------------------------------------------
by stof at 2012-07-24T14:37:27Z
tests are also missing
---------------------------------------------------------------------------
by kufi at 2012-07-27T08:50:05Z
Ok. Moved the Listeners into own classes. Changed the names of the types. Fixed the TranslationCollectionType which now is a Subclass of AbstractType and has the parent collection.
Edit:
The syntax changed slighty for the form:
$builder->add('pageI18ns', new \Symfony\Bridge\Propel1\Form\Type\TranslationCollectionType(), array(
'languages' => array('de', 'fr', 'en'),
'label' => 'Translations',
'options' => array(
'data_class' => 'foo\bar\Modell\PageI18n',
'columns' => array(
'title' => array(
'label' => 'Custom title',
),
'description' => array(
'type' => 'textarea'
)
)
)
));
---------------------------------------------------------------------------
by stof at 2012-07-27T08:55:07Z
tests are still missing, and you have some CS issue (which can probably all be fixed by running the [PHP-CS-Fixer](http://cs.sensiolabs.org/) on your classes)
---------------------------------------------------------------------------
by sindro88 at 2012-08-13T13:27:46Z
I followed step by step the implementation but the form type return an error "Could not load type propel1_translation".
---------------------------------------------------------------------------
by kufi at 2012-08-14T06:21:40Z
Could you try again. The problem was that the type propel1_translation_collection relied on a registered form type propel1_translation. I removed this one and replaced it with the actual form class.
---------------------------------------------------------------------------
by sindro88 at 2012-08-14T06:35:33Z
I replaced with the class and now it work, thank you so much!
---------------------------------------------------------------------------
by fabpot at 2012-09-18T16:53:21Z
ping @willdurand
---------------------------------------------------------------------------
by stof at 2012-10-13T17:56:16Z
@willdurand ping
---------------------------------------------------------------------------
by willdurand at 2012-10-23T12:03:22Z
There are a few comments by @stloyd to fix, but I'm 👍 on this PR.
---------------------------------------------------------------------------
by fabpot at 2012-10-23T13:18:59Z
@kufi Can you add a note in the CHANGELOG of the Propel bridge before I merge this PR? Thanks.
---------------------------------------------------------------------------
by kufi at 2012-10-23T13:32:31Z
@fabpot Sure. Does this belong to Version 2.1.0 or the upcoming 2.2.0?
---------------------------------------------------------------------------
by fabpot at 2012-10-23T13:59:04Z
2.2
* 2.1:
[ClassLoader] fixed unbracketed namespaces (closes#5747)
slight refactoring in UrlMatcher
[Form] Created test for DoctrineOrmTypeGuesser see #5790
[Form] Fixed DoctrineOrmTypeGuesser to guess the "required" option for to-one associations
This PR was merged into the 2.1 branch.
Commits
-------
5d2525b [Form] Created test for DoctrineOrmTypeGuesser see #5790b844d6b [Form] Fixed DoctrineOrmTypeGuesser to guess the "required" option for to-one associations
Discussion
----------
[Form] Doctrine orm type guesser tests
This PR adds tests to https://github.com/symfony/symfony/pull/5790
---------------------------------------------------------------------------
by Tobion at 2012-10-20T10:53:56Z
Using real test entities would be better IMO. Using mocks ties it pretty much to the implementation.
---------------------------------------------------------------------------
by sstok at 2012-10-21T10:38:53Z
@Tobion thats true, but Doctrine Class meta data takes quite some coding to set-up.
For instance you need the EntityManager to get even get the meta data set!
So you'd end having more code to set-up then your actually testing.
---------------------------------------------------------------------------
by Burgov at 2012-10-21T12:58:58Z
I wasn't sure whether do use a test entity manager, or do it the way I finally did it.
@sstok true, it's quite some work to set it up, but on the other hand there's the base OrmTestCase class which does it for you, so it'd actually mean I'd only have to create one entity for all the cases: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/Tests/DoctrineOrmTestCase.php
@Tobion on the other hand I tend to use a test EM only when I actually need to test persisting and loading, while this test case here is so isolated that I didn't really feel it would be necessary.
I'd like to know which method is preferred though, I'll change it if necessary, and other tests can be added to test the rest of this specific class
This PR was merged into the master branch.
Commits
-------
b31ae34 [WebProfilerBundle] Remove the now unneeded BC var and fixed a typo
d07ce03 [TwigBundle] Moved the registration of the app global to the environment
Discussion
----------
[TwigBundle] Moved the registration of the app global to the environment
This makes the app global variable available also when accessing the Twig
environment directly instead of using the TwigEngine.
* 2.1:
fixed CS
added doc comments
added doc comments
[Validator] Updated swedish translation
Update src/Symfony/Component/Validator/Resources/translations/validators.de.xlf
[2.1] Exclude tests from zips via gitattributes
[HttpKernel][Translator] Fixed type-hints
Updated lithuanian validation translation
[DomCrawler] Allows using multiselect through Form::setValues().
[Translation] forced the catalogue to be regenerated when a resource is added (closes symfony/Translation#1)
Unit test for patched method OptionsResolver::validateOptionValues().
validateOptionValues throw a notice if an allowed value is set and the corresponding option isn't.
[Form] Hardened code of ViolationMapper against errors
[HttpFoundation] Fixed#5611 - Request::splitHttpAcceptHeader incorrect result order.
[Form] Fixed negative index access in PropertyPathBuilder
Update src/Symfony/Component/Validator/Resources/translations/validators.ro.xlf
Conflicts:
src/Symfony/Component/DomCrawler/Form.php
src/Symfony/Component/Process/Process.php
* 2.1:
[2.1] Fix SessionHandlerInterface autoloading
Remove executable bit from HttpKernel/DependencyInjection/ConfigurableExtension.php
[2.0][http-foundation] Fix Response::getDate method
[DoctrineBridge] Require class option for DoctrineType
[HttpFoundation] fixed the path to the SensioHandlerInterface class in composer.json
Support the new Microsoft URL Rewrite Module for IIS 7.0. @see http://framework.zend.com/issues/browse/ZF-4491 @see http://framework.zend.com/code/revision.php?repname=Zend+Framework&rev=24842
fixed undefined variable
hasColorSupport does not take an argument
Improve FilterResponseEvent docblocks Response ref
Commits
-------
83dc966 [Form] Fixed some PHPDoc
596bbb1 [Form] fixed FormConfigBuilder to use PropertyPathInterface
a523823 [Form] fixed and added phpDoc
Discussion
----------
[Form] fixed and added phpDoc
[ci skip]
---------------------------------------------------------------------------
by sstok at 2012-08-26T08:11:01Z
Some descriptions don''t seem to be properly aligned, use the CS-fixer.
---------------------------------------------------------------------------
by Tobion at 2012-08-26T17:02:25Z
@sstok This is more about manual fixes concerning forgotten exceptions or wrong data type. The cs fixer gives many false positives and can be applied later.
Commits
-------
f1c4b8b [Doctrine Bridge] Added a parameter ignoreNull on Unique entity to allow a nullable value on field. Added Test
Discussion
----------
[Doctrine Bridge] Added parameter ignoreNull to accept a nullable value on field
In my last project, i use this syntax to test unicity on 2 fields, but it fail because the validator stop if value is null. I dropped the test on validator and my unicity work fine.
```
@UniqueEntity(fields={"username", "deletedAt"})
```
It's possible to add this PR on Bridge.
Thanks
Bertrand
---------------------------------------------------------------------------
by stof at 2012-07-23T08:14:19Z
This is wrong. RDBMS allow several null values in a unique column and this change will break it.
---------------------------------------------------------------------------
by henrikbjorn at 2012-07-23T08:17:08Z
@stof seems weird indeed it would return if any of the values are null. Makes sense to do a query where the field `IS NULL` or whatever the find method does.
---------------------------------------------------------------------------
by stof at 2012-07-23T08:18:50Z
@henrikbjorn if you do a query with IS NULL, the validator would force to have only 1 entity with a null field whereas it is not the behavior of the DB-level constraint.
---------------------------------------------------------------------------
by henrikbjorn at 2012-07-23T08:20:41Z
In this case i suspect that he wants to achieve a `WHERE username = "henrikbjorn" AND deletedAt IS NULL` which would be valid right? Currently it just returns if any of the fields are null and the validation is never done.
---------------------------------------------------------------------------
by bschussek at 2012-07-23T08:27:24Z
I suggest to make this configurable as the handling of NULL values in UNIQUE columns [differs between SQL implementations](http://forums.mysql.com/read.php?22,53591,53591#msg-53591).
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T08:52:53Z
@stof What the correct solution to test my unicity with deletedAt == null ?
I use this definition: @ORM\Column(name="deleted_at", type="datetime", nullable=true)
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:28:44Z
In my local repository, i added a new parameter "$authorizedNullField" on UniqueEntity.php and tested this on UniqueEntityValidator.php:
Code: https://gist.github.com/4122efbe569e3c2c95c0
What about that ?
Thanks for your help
---------------------------------------------------------------------------
by stof at 2012-07-23T20:45:30Z
yep, this would be good (except for the naming which seems weird)
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:46:44Z
No problem to change this. I don't find a good name for this ?
---------------------------------------------------------------------------
by stof at 2012-07-23T20:47:57Z
what about ``allowMultipleNull`` (defaulting to ``true`` for BC) ?
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:51:30Z
Why multiple ? This option is for one or many. what about `allowNullable` ?
---------------------------------------------------------------------------
by stof at 2012-07-23T20:52:44Z
@Garfield-fr the current behavior allows having multiple null values without failing to the unique constraint
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:56:07Z
ok. I make `allowMultipleNull`.
It's ok with that: https://gist.github.com/cae8d43780c45a5011ed
Thanks
---------------------------------------------------------------------------
by bschussek at 2012-07-23T20:58:12Z
What about `uniqueNull` (`false` by default)? `ignoreNull` (`true` by default)? I find `allowMultipleNull` a bit cumbersome.
---------------------------------------------------------------------------
by stof at 2012-07-23T20:58:26Z
no it is not. You have an issue in the validator. You have an extra negation.
Please update your PR
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T21:01:59Z
@stof `ignoreNull` is ok for you ?
---------------------------------------------------------------------------
by stof at 2012-07-23T21:10:24Z
yes
---------------------------------------------------------------------------
by fabpot at 2012-08-05T07:48:03Z
Is it mergeable now? Is yes, @Garfield-fr Can you squash your commits?
---------------------------------------------------------------------------
by travisbot at 2012-08-05T08:43:23Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2039523) (merged 19ae3cf9 into c20c1d18).
---------------------------------------------------------------------------
by stof at 2012-08-05T12:09:02Z
@Garfield-fr when squashing the commits, you need to force the push as you are rewriting the history. You should not have merged with your remote branch
---------------------------------------------------------------------------
by Garfield-fr at 2012-08-05T12:10:15Z
What's the right solution for resolve this ?
---------------------------------------------------------------------------
by stof at 2012-08-05T12:11:09Z
@Garfield-fr reset your local branch to the squashed commit and force the push
---------------------------------------------------------------------------
by Garfield-fr at 2012-08-05T12:14:09Z
@stof Thanks for your help
---------------------------------------------------------------------------
by travisbot at 2012-08-05T12:19:06Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2040210) (merged f1c4b8b4 into 20d2e5a1).
Commits
-------
fb002d8 [Form] Fixed variable passing from outer to inner blocks of the same FormView instance
Discussion
----------
[Form] Fixed variable passing from outer to inner blocks of the same FormView instance
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5029
Todo: -
This PR fixes two bugs.
The first bug is described in #5029. The second parameter to the "form_label" function in Twig, if given, always overwrote whatever label was defined previously.
```
{# null would overwrite whatever is currently set #}
form_label(form, null, { ... })
```
The second bug affected passing variables from outer to inner blocks. In the following example, "label_attr" would not be forwarded to the "form_label" function.
```
form_row(form, { "label_attr": { "class": "my_class" }})
```
Both bugs are fixed now.
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
👍
