Commits
-------
22cb817 Caching variables for the PHP templating engine
Discussion
----------
[Templating] PHP templating engine speed-ups
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/dlsniper/symfony.png?branch=php-engine-escape-cache)](http://travis-ci.org/dlsniper/symfony)
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
This PR should improve the speed for rendering the form present here: https://github.com/dlsniper/symfony-standard . On my computer, Ubuntu 12.04 Apache 2.2.22 + mod_php 5.3.10 default packages from Ubuntu on a core i7 I get about 30-40ms improvement / request with the first commit and with the second one I get a further smaller boost and also a small memory usage decrease.
---------------------------------------------------------------------------
by dlsniper at 2012-07-31T06:18:54Z
ping @bschussek This should help a bit more on the effort for optimizing the example provided for the Forms component.
If there's another example of complex form(s) let me know so that I can have a look on them as well. Thanks!
---------------------------------------------------------------------------
by travisbot at 2012-07-31T19:55:03Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2003907) (merged 240152b9 into a172a812).
---------------------------------------------------------------------------
by dlsniper at 2012-08-02T07:41:03Z
@fabpot what do you think about this? or anyone else for that matter?
---------------------------------------------------------------------------
by travisbot at 2012-08-02T12:55:54Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2018613) (merged 5e773e79 into a172a812).
---------------------------------------------------------------------------
by fabpot at 2012-08-03T07:42:31Z
Can you squash your commits?
---------------------------------------------------------------------------
by dlsniper at 2012-08-03T08:32:05Z
@fabpot Done
---------------------------------------------------------------------------
by travisbot at 2012-08-03T08:40:46Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2026559) (merged 22cb8173 into 6f32078b).
Commits
-------
0b78fdf Only call registerCommand on bundles that is an instance of Bundle
Discussion
----------
Only call registerCommand on bundles that is an instance of Bundle
Fixes GH-5133
---------------------------------------------------------------------------
by travisbot at 2012-08-01T09:41:05Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2008252) (merged 0b78fdff into 1da896dc).
---------------------------------------------------------------------------
by henrikbjorn at 2012-08-01T10:05:00Z
Build failed because of HTTP request error.
---------------------------------------------------------------------------
by lsmith77 at 2012-08-01T11:31:08Z
wondering if it would be good if you could include the commit from #5133 in this PR .. then we get the test and the fix at once.
Commits
-------
30bcb57 Added a test case to demonstrate the fatal error occuring when a Bundle implementing BundleInterface only is registered in the kernel.
Discussion
----------
Fatal error in FrameworkBundle console application
A fatal error is generated in the `FrameworkBundle` console application when a bundle is added implementing [`BundleInterface`](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Bundle/BundleInterface.php)
This is because the method `registerCommands` does not exist on this interface and is instead only defined on the concrete [`Bundle`](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Bundle/Bundle.php#L173) implementation.
The workaround for this issue is simple - implement an empty method for `registerCommands` in the bundle implementation so that the fatal error is not triggered.
However this issue should probably be fixed by either restricting bundles to the Bundle class or expanding the `BundleInterface` to include the `registerCommands` method signature. Both of these fixes will introduce a BC break into the API so I would suggest creating a fix for 2.0 which includes method detection in the `registerCommands` method of the [`Console\Application`](https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Console/Application.php#L80) class.
I'm happy to submit the fix for this - however I would like some direction from the SF2 dev team as to which way they would like to resolve this.
The PR currently only contains a unit test that proves this behaviour.
---------------------------------------------------------------------------
by travisbot at 2012-08-01T02:42:55Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2006350) (merged 30bcb572 into 1da896dc).
---------------------------------------------------------------------------
by henrikbjorn at 2012-08-01T05:50:16Z
I am thinking a instanceof check might be the most reasonable in this case. But in master it should proberly be fixed by adding the method to the interface.
/cc @stof any comments if that is to be done?
---------------------------------------------------------------------------
by stof at 2012-08-01T08:53:02Z
yeah, for 2.0, we cannot change the interface.
Commits
-------
6b0dcbb MD format fix
Discussion
----------
Md format fix
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: -
Small format fixes in CHANGELOG-2.0.md.
---------------------------------------------------------------------------
by travisbot at 2012-08-03T06:23:27Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2025980) (merged 6b0dcbb7 into 1da896dc).
OptionsResolver#validateOptionsCompleteness would already have thrown exception if the option were required, so this should only affect something explicitly marked as optional
Commits
-------
4ae54e3 [Composer] Bumped doctrine/orm to 2.2.3
Discussion
----------
[Composer] Bumped doctrine/orm to 2.2.3
fix#4966
---------------------------------------------------------------------------
by stloyd at 2012-07-31T15:01:41Z
You should also _bump_ Security component [deps](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/composer.json#L28).
---------------------------------------------------------------------------
by vicb at 2012-07-31T15:05:03Z
The security does not depend on `doctrine/orm`
Commits
-------
b982883 [Form] Moved FormHelper back to FrameworkBundle
cb62d05 [Form] [Validator] Fixed issues mentioned in the PR
2185ca8 [Validator] Added entry point "Validation" for more convenient usage outside of Symfony2
ed87361 [Form] Moved FormHelper creation to TemplatingExtension
87ccb6a [Form] Added entry point "Forms" for more convenient usage outside of Symfony
Discussion
----------
[Form] [Validator] Added more convenient entry points for stand-alone usage
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR greatly simplifies the usage of the Form and Validator component when used outside of Symfony2. Check out the below code to get an idea about the simplified usage:
```php
<?php
use Symfony\Component\Validator\Validation;
use Symfony\Component\Validator\Mapping\Cache\ApcCache;
use Symfony\Component\Form\Forms;
use Symfony\Component\Form\Extension\HttpFoundation\HttpFoundationExtension;
use Symfony\Component\Form\Extension\Csrf\CsrfExtension;
use Symfony\Component\Form\Extension\Csrf\CsrfProvider\SessionCsrfProvider;
use Symfony\Component\Form\Extension\Templating\TemplatingExtension;
use Symfony\Component\Form\Extension\Validator\ValidatorExtension;
use Symfony\Component\HttpFoundation\Session;
use Symfony\Component\Templating\PhpEngine;
$session = new Session();
$secret = 'V8a5Z97e...';
$csrfProvider = new SessionCsrfProvider($session, $secret);
$engine = new PhpEngine(/* ... snap ... */);
$validator = Validation::createValidator();
// or
$validator = Validation::createValidatorBuilder()
->addXmlMapping('path/to/mapping.xml')
->addYamlMapping('path/to/mapping.yml')
->addMethodMapping('loadValidatorMetadata')
->enableAnnotationMapping()
->setMetadataCache(new ApcCache())
->getValidator();
$formFactory = Forms::createFormFactory();
// or
$formFactory = Forms::createFormFactoryBuilder()
// custom types, if you're too lazy to create an extension :)
->addType(new PersonType())
->addType(new PhoneNumberType())
->addTypeExtension(new FormTypeHelpTextExtension())
// desired extensions (CoreExtension is loaded by default)
->addExtension(new HttpFoundationExtension())
->addExtension(new CsrfExtension($csrfProvider))
->addExtension(new TemplatingExtension($engine, $csrfProvider, array(
'FormBundle:Form'
))
->addExtension(new ValidatorExtension($validator))
->getFormFactory();
$form = $formFactory->createBuilder()
->add('firstName', 'text')
->add('lastName', 'text')
->add('age', 'integer')
->add('gender', 'choice', array(
'choices' => array('m' => 'Male', 'f' => 'Female'),
))
->getForm();
if (isset($_POST[$form->getName()])) {
$form->bind($_POST[$form->getName()]);
if ($form->isValid()) {
// do stuff
}
}
return $engine->render('AcmeHelloBundle:Hello:index.html.php', array(
'form' => $form->createView(),
));
```
---------------------------------------------------------------------------
by bschussek at 2012-07-30T10:08:42Z
I should maybe add a comment about the benefits of this change, in case they are not self-explanatory:
* class construction with default configuration is now a one-liner
* userland code is decoupled from core implementations → userland code doesn't break if we change constructor signatures
* easier to understand, since many core classes are now created internally
* easy to discover the possible settings → just look at (FormFactory|Validator)BuilderInterface
* usage of custom interface implementations is supported, just like before
---------------------------------------------------------------------------
by fabpot at 2012-07-31T08:18:53Z
The new syntax is great.
I have one comment though about this PR about support of PHP as a templating system (support for Twig is provided by the bridge and it was already easy to configure Twig as a templating system for forms -- see Silex for instance).
The `FormHelper` has been moved into the Form component. This helper is only useful when using the PHP templating system (which is not what we recommend people to use), but the default templates are still in the Framework bundle. So using the Form component as standalone with PHP as a templating system still requires to install the bundle to get access to the default templates. Am I missing something? Do we want to move the PHP templates to the Form component too?
---------------------------------------------------------------------------
by stof at 2012-07-31T08:28:28Z
@fabpot it is even worse than that: the FormHelper currently uses the theme by using ``$theme . ':' . $block . '.html.php`` IIRC. This is not compatible with the default template name parser of the component expecting a path. And the FrameworkBundle template name parser does not support accessing a template outside a bundle AFAIK.
So moving the templating to the component would require some refactoring in the FormHelper and the template name parser. However, I think it is worth it. Some people complained that using the form rendering (outside the full-stack framework) was requiring either setting up Twig with the bridge, or adding FrameworkBundle in the project (which means including most of the code of the full-stack framework). Having the Templating rendering in the standalone component could be a great idea
---------------------------------------------------------------------------
by fabpot at 2012-07-31T08:42:53Z
But then, I don't want to promote the Templating component or the PHP templating system. Twig is always a better alternative and this should be what people use most of the time, PHP being the rare exception.
Anyway, we are too close from the first 2.1 RC, so any big refactoring will have to wait for 2.2.
---------------------------------------------------------------------------
by stof at 2012-07-31T09:02:10Z
then maybe we should keep the FormHelper in FrameworkBundle for now as it is tied to the FrameworkBundle template name parser anyway currently.
---------------------------------------------------------------------------
by bschussek at 2012-07-31T14:22:35Z
> it it is even worse than that: the FormHelper currently uses the theme by using ``$theme . ':' . $block . '.html.php`` IIRC. This is not compatible with the default template name parser of the component expecting a path.
This is why the templates are still in FrameworkBundle. I think they should be moved too, but then we have to change
* the default theme to an absolute file path
* the FrameworkBundle name parser to accept absolute paths
I think this can wait until 2.2. Baby steps.
> I don't want to promote the Templating component or the PHP templating system.
We can both promote Twig while making Templating as easy to use as possible. If people want to use Templating, they probably have a reason. We don't have to make their lives more painful than necessary.
Btw: Templating is a *lot* faster for rendering forms than Twig. On Denis' form, Templating takes 1.15 seconds while Twig takes 2.
About moving the helpers, we have two choices:
* Move each helper to the respective component. This would not require new releases of the Templating component when we add more helpers in other component.
* Move all helpers to Templating. This does not make that much sense for Form, as then Form has support for Templating (TemplatingRendererEngine) and Templating has support for Form (FormHelper), which is a bit weird. I personally prefer a stacked architecture, where Templating is at the bottom and Form-agnostic, and Form (or any other component) builds upon that.
I'm fine with both approaches. I'll move FormHelper back to FrameworkBundle, and we can decide for a direction in 2.2.
---------------------------------------------------------------------------
by bschussek at 2012-07-31T14:36:30Z
Done.
Commits
-------
03bbaaf [Routing] Add an interface for configuring strict_parameters
Discussion
----------
[RFC][Routing] Add an interface for configuring strict_parameters
This is a proposal to fix#4697 (related to #4592).
The main point left to discuss was the name of the interface, which is now `LenientInterface`. We could change the name to anything else is someone has a better idea.
@stof @Tobion what do you think ?
---------------------------------------------------------------------------
by stof at 2012-07-30T16:34:20Z
@vicb I already said I had no idea to name it, and it has not changed. :)
So let's wait for other people to see if they have a better idea
---------------------------------------------------------------------------
by breerly at 2012-07-30T16:38:38Z
Maybe `PermissibleInterface` or `PermissiveInterface`.
---------------------------------------------------------------------------
by Partugal at 2012-07-30T17:00:09Z
`StrictUrlGeneratorInterface`, `StrictParametersInterface` or `StrictInterface`
---------------------------------------------------------------------------
by pborreli at 2012-07-30T17:04:46Z
👍 for `PermissiveInterface`
---------------------------------------------------------------------------
by stof at 2012-07-30T17:07:59Z
yes, because the Router currently can only use this interface to set it to ``not-strict``. It assumes that the url generator is already strict by default (which is probably a bad assumption btw as the base class for the generated generator can be changed)
---------------------------------------------------------------------------
by pborreli at 2012-07-30T17:09:33Z
@stof thx, got it
---------------------------------------------------------------------------
by Partugal at 2012-07-30T17:10:03Z
this interface realize setting Strict by setStrictParameters, and get by getStrictParameters, and imho named it by `Strictable` is more logic
---------------------------------------------------------------------------
by pborreli at 2012-07-30T17:11:07Z
@Partugal let's try to find an english term :)
---------------------------------------------------------------------------
by Partugal at 2012-07-30T17:11:31Z
)
---------------------------------------------------------------------------
by breerly at 2012-07-30T17:15:23Z
@Partugal I like using "able" in interface names because it describes a behavior instead of a noun. This type of naming makes following the Interface Segregation Principle easy to follow. Good work.
---------------------------------------------------------------------------
by vicb at 2012-07-30T18:24:26Z
As explained by @stof I did not consider `StrictInterface` because as of now the interface is used to disabled the strict bevahior (which is enabled by default).
I am not satisfied with `PermissiveInterface` / `LenientInterface` because implementing this interface does not mean that the generator will be permissive but only that the behavior is configurable - yes I did consider `Configurable` but the term is a too vague.
---------------------------------------------------------------------------
by breerly at 2012-07-30T18:35:45Z
I see. Perhaps ```StrictConfigurableInterface``` would do the trick.
---------------------------------------------------------------------------
by Tobion at 2012-07-30T21:02:21Z
I think renaming strict_parameters to `strict_requirements` is the way to go because it determines how requirements are handled when generating a URL. Also we should allow another option:
strict_requirements = true: throw exception for mismatching requirements
strict_requirements = null: return null as URL for mismatching requirements and log it.
strict_requirements = false: return the URL with the given parameters without checking the requirements and don't log it.
(Maybe use constants for these).
The Interface I would then call `ConfigurableRequirementsInterface` or `RequirementsHandlingInterface`.
---------------------------------------------------------------------------
by vicb at 2012-07-31T07:23:24Z
Thanks all for the feeback, this is what is now implemented:
- A `ConfigurableRequirementsInterface` that should be implemented by generators that can be configure not to throw an exception when the parameters do not match the requirements,
- The interface has two methods: `setStrictRequirements()` and `isStrictRequirements()`,
- `setStrictRequirements()` always gets called to configure the generator (whatever the option value is)
Note: The Router option name has not changed (i.e. `strict_parameters`)
Does that fit everyone ?
---------------------------------------------------------------------------
by vicb at 2012-07-31T07:39:22Z
So the option name is now consistent (`strict_requirements`) with the interface. We should sync the change [in the standard edition](https://github.com/symfony/symfony-standard/blob/master/app/config/config.yml#L11) if we agree to merge this.
---------------------------------------------------------------------------
by fabpot at 2012-07-31T07:51:47Z
@vicb you forgot to rename the property in `UrlGenerator` as @stof mentioned above.
---------------------------------------------------------------------------
by vicb at 2012-07-31T07:59:57Z
@fabpot fixed. If the code is ok, I'll squash the commits and open a PR on symfony-standard
Commits
-------
a47922b [OptionsResolver] Fix Options::has() when the value is null
Discussion
----------
[OptionsResolver] Fix Options::has() when the value is null
`isset()` would have returned `false` when the value is `null`
Commits
-------
57ac110 [Form] Removed unnecessary method call
27ab56d [OptionsResolver] Removed LazyOption class and improved performance a tiny bit
Discussion
----------
[OptionsResolver] Removed LazyOption class and improved performance
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Commits
-------
04cb5bc [Form] Removed the ImmutableFormConfig class to save time spent with copying values (+20ms)
Discussion
----------
[Form] Removed the ImmutableFormConfig class to improve performance
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Performance gain: 20ms
Commits
-------
a845a28 [Form] Optimized form events to only be created on demand
Discussion
----------
[Form] Optimized form events to only be created on demand
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Commits
-------
03c3712 [Filesystem] Fixed 2 tests throwing error on windows
3689bb8 [Filesystem] Fixed 3 failing tests on windows
Discussion
----------
[Filesystem] Fixed 5 tests on windows
Fixing 3 test expecting wrong folders :
```
-'C:\Users\pascal\AppData\Local\Temp\\1343425847694\file'
+'C:\Users\pascal\AppData\Local\Temp\1343425847694\file'
```
Fixed 2 tests on Windows caused by symlink function throwing error when first argument is not existent :
```
symlink(): Could not fetch file information(error 2)
```
Commits
-------
f402a16 [FrameworkBundle] AssetsInstallCommand. Made 'web' as a default folder.
Discussion
----------
[FrameworkBundle] AssetsInstallCommand. Made 'web' as a default folder.
Bug fix: no
Feature addition: yes
Backwards compatibility break: not sure
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
>'The target directory (usually "web")'
It is indeed a folder that's usually used to install assets, why not making it as a default value?
Commits
-------
76815fe Allow the targetUrl on a redirect response to be set explicilty.
Discussion
----------
Allow the targetUrl on a redirect response to be set explicilty.
Currently, RedirectResponse gets a Url set only when it's created, in the constructor. There is no way to change it later. That's a problem, because then you cannot change that Url from, say, a Kernel.response event listener. That's a use case that Drupal in particular needs, because on redirects we allow modules to change the redirect target. We also allow for redirect overrides via a GET parameter.
This PR refactors RedirectResponse to allow for a setTargetUrl() method. It gets called from the constructor now, and can also be called from wherever. It does not deal with changing the status code, just the Url (and by implication the content body).
Hopefully I got the coding style right this time... :-)
---------------------------------------------------------------------------
by vicb at 2012-07-27T15:45:47Z
> Currently, RedirectResponse gets a Url set only when it's created, in the constructor. There is no way to change it later. That's a problem, because then you cannot change that Url from, say, a Kernel.response event listener.
You can not change the target URL, but you can create a new `RedirectResponse` to override the original one (by calling `$event->setResponse()` in the listener).