[Form] Added entry point "Forms" for more convenient usage outside of Symfony
[Form] Moved FormHelper creation to TemplatingExtension
[Validator] Added entry point "Validation" for more convenient usage outside of Symfony2
[Form] [Validator] Fixed issues mentioned in the PR
[HttpKernel] added a way to override the default response status code when handling an exception (closes #5043)
fixed typo
merged branch bamarni/patch-3 (PR #5125)

Commits
-------

f84f5fd fixed typo

Discussion
----------

fixed typo
[Routing] Add an interface for configuring strict_parameters
merged branch vicb/lenient_generator (PR #5114)

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

:+1: 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
[Form] Moved FormHelper back to FrameworkBundle
merged branch bschussek/bootstrap (PR #5112)

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.
[Composer] Bumped doctrine/orm to 2.2.3
merged branch vicb/doctrine_deps (PR #5127)

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`