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).
Commits
-------
b384c82 [HttpFoundation] Fixed checking IPv6 address without bit-length of the prefix
Discussion
----------
[HttpFoundation] Fixed checking IPv6 address without bit-length of the p...
...refix
Replaces #5031
Commits
-------
ae6016c [Finder] Workaround for FilterIterator-FilesystemIterator-rewind issue
Discussion
----------
[Finder] Workaround for the problem with rewind of FilterIterator with inner FilesystemIterator.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4922
Todo: -
License of the code: MIT
Documentation PR: -
---------------------------------------------------------------------------
by stof at 2012-07-20T10:28:05Z
Please add some tests
---------------------------------------------------------------------------
by alebo at 2012-07-24T09:50:36Z
Any feedback yet? The new commit includes tests.
