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`
OptionsResolver#validateOptionTypes should check if option value exists before checking its type; added corresponding test

OptionsResolver#validateOptionsCompleteness would already have thrown exception if the option were required, so this should only affect something explicitly marked as optional
Added a test case to demonstrate the fatal error occuring when a Bundle implementing BundleInterface only is registered in the kernel.
Only call registerCommand on bundles that is an instance of Bundle

Fixes GH-5133
[DoctrineBridge] Fix log of non utf8 data
Added before/after examples of change in registering security factories to upgrade info.
MD format fix
merged branch richardmiller/adding_example_to_upgrade_info (PR #5153)

Commits
-------

2c3a7bf Added before/after examples of change in registering security factories to upgrade info.

Discussion
----------

Added before/after examples of change in registering security factories ...

...to upgrade info.
merged branch gajdaw/md_format_fix (PR #5160)

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).
merged branch web-dev/bundle-interface-command-fatal-error (PR #5133)

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.
merged branch henrikbjorn/2.0 (PR #5137)

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.
[DoctrineBridge] Fix log of non utf8 data
fix phpdoc statement of getAlias()
removed unused private property
Caching variables for the PHP templating engine
merged branch dlsniper/php-engine-escape-cache (PR #5117)

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).