Commit Graph

10656 Commits

Author SHA1 Message Date
Bernhard Schussek
5984b18a7a [Form] Precalculated the closure for deciding whether a choice is selected (PHP +30ms, Twig +30ms) 2012-07-21 12:56:50 +02:00
Bernhard Schussek
5dc3c39fd2 [Form] Moved the access to templating helpers out of the choice loop for performance reasons (PHP +100ms) 2012-07-21 12:56:50 +02:00
Bernhard Schussek
0ef9acb479 [Form] Moved the method isChoiceSelected() to the ChoiceView class (PHP +150ms) 2012-07-21 12:56:50 +02:00
Bernhard Schussek
8b72766473 [Form] Tweaked the generation of option tags for performance (PHP +200ms, Twig +50ms) 2012-07-21 12:56:50 +02:00
Bernhard Schussek
400c95bb4d [Form] Replace methods in ChoiceView by public properties (PHP +100ms, Twig +400ms) 2012-07-21 12:56:11 +02:00
Bernhard Schussek
d072f35ea0 [Form] The properties of FormView are now accessed directly in order to increase performance (PHP +200ms, Twig +150ms) 2012-07-21 12:56:11 +02:00
Fabien Potencier
9f157a1616 merged branch docteurklein/unique-entity-validator-with-custom-repository-method (PR #4979)
Commits
-------

4eb54a0 update CHANGELOG
db9ea09 [Doctrine] [Bridge] fix repositoryMethod test
2a6c222 Add a customRepository option to the uniqueEntity validator

Discussion
----------

[Doctrine] [Bridge] Add a "repositoryMethod" option to the uniqueEntity validator

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~

This allows to configure the repository method used to verify uniqueness of entity.
Before, it was always using `findBy`.

---------------------------------------------------------------------------

by fabpot at 2012-07-20T05:35:28Z

Can you add a note in the CHANGELOG?

---------------------------------------------------------------------------

by docteurklein at 2012-07-20T07:17:08Z

@fabpot done.
2012-07-20 11:35:08 +02:00
Klein Florian
4eb54a042d update CHANGELOG 2012-07-20 09:25:13 +02:00
Fabien Potencier
4bde2aac41 merged 2.0 2012-07-20 07:34:13 +02:00
Fabien Potencier
112a51392a merged branch vicb/response/statuscode (PR #4980)
Commits
-------

ed8823c [HttpFoundation] Allow setting an unknown status code without specifying a text

Discussion
----------

[HttpFoundation] Allow setting an unknown status code without specifying...

... a text

fix #4978
2012-07-20 07:30:32 +02:00
Fabien Potencier
c0fc40013a merged branch eko/2.0 (PR #4983)
Commits
-------

16a980b [Validator] Fix bug order for constraint, property, getter and group-sequence-provider in validation.xml

Discussion
----------

[Validator] Fix bug order for constraint, property, getter and group-seq...

Actually, there is a bug that force developers to write validation.xml file with the following nodes order:

- constraint
- property
- getter

So that's not possible to have the following XML (because I need to write my property(ies) first).

```xml
<?xml version="1.0" encoding="UTF-8" ?>
<constraint-mapping xmlns="http://symfony.com/schema/dic/constraint-mapping"
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                    xsi:schemaLocation="http://symfony.com/schema/dic/constraint-mapping http://symfony.com/schema/dic/constraint-mapping/constraint-mapping-1.0.xsd">

    <class name="Application\Eko\MyBundle\Entity\MyEntity">
        <getter property="isBar">
            <constraint name="True">
                <option name="message">My error message</option>
            </constraint>
        </getter>

        <property name="foo">
            <constraint name="NotBlank" />
        </property>
    </class>

</constraint-mapping>
```

The XML below result in the following exception:

```
[ERROR 1871] Element '{http://symfony.com/schema/dic/constraint-mapping}property': This element is not expected. Expected is ( {http://symfony.com/schema/dic/constraint-mapping}getter ). (in /var/www/myproject/src/Application/Eko/MyBundle/Resources/config/validation.xml - line 14, column 0)
```

This is due to the sequence element that needs to respect the order given in the schema file.

The choice element is doing the same thing and permit to have a free order of elements so I have replaced the sequence by a choice element.

For more information: http://www.w3.org/TR/xmlschema-0/#ref17
2012-07-20 07:29:27 +02:00
Fabien Potencier
7d2f814a03 Merge branch '2.0'
* 2.0:
  [Console] Use proc_open instead of exec to suppress errors when run on windows and stty is not present
2012-07-20 07:27:52 +02:00
Jordi Boggiano
4f93d1addd [Console] Use proc_open instead of exec to suppress errors when run on windows and stty is not present 2012-07-20 07:25:32 +02:00
Fabien Potencier
503899e26c merged branch Seldaek/rename (PR #4986)
Commits
-------

c81b2ad [Form] Rename UnmodifiableFormConfig to ImmutableFormConfig
274eb9e [EventDispatcher] Rename UnmodifiableEventDispatcher to ImmutableEventDispatcher

Discussion
----------

Rename unmodifiable to immutable

Maybe it's just me, but it sounded really wrong. The EventDispatcher one was added in 2.1 so no BC break. I don't know about the Form one, but I guess it's just used internally anyway.
2012-07-20 07:16:03 +02:00
Fabien Potencier
b201812927 merged branch Fran6co/fix-security-handlers (PR #4985)
Commits
-------

39157a8 [Security] fixes multiple overlapping definitions of DefaultFailureHandler and DefaultSuccessHandler in AbstractFactory

Discussion
----------

[Security] fixes multiple overlapping definitions of DefaultFailureHandler and DefaultSuccessHandler in AbstractFactory

If more than one listener extends AbstractFactory, you'll have multiple calls to createAuthenticationFailureHandler and createAuthenticationSuccessHandler with the same id.

Implicitly it's going to use the one generated by the last factory generating unexpected behavior.

This is related to commits 915704c071 and c6aa392df7
2012-07-20 07:15:13 +02:00
Fabien Potencier
a7c0b7f6e1 merged branch Tobion/patch-3 (PR #4984)
Commits
-------

d85650d [Validator] remove return value in TrueValidator

Discussion
----------

[Validator] remove return value in TrueValidator
2012-07-20 07:12:22 +02:00
Jordi Boggiano
c81b2ad3e2 [Form] Rename UnmodifiableFormConfig to ImmutableFormConfig 2012-07-20 01:18:42 +02:00
Jordi Boggiano
274eb9ebaf [EventDispatcher] Rename UnmodifiableEventDispatcher to ImmutableEventDispatcher 2012-07-20 01:18:14 +02:00
Francisco Facioni
39157a852d [Security] fixes multiple overlapping definitions of DefaultFailureHandler and DefaultSuccessHandler in AbstractFactory 2012-07-19 19:25:03 -03:00
Tobias Schultze
d85650d29f [Validator] remove return value in TrueValidator 2012-07-19 23:47:59 +03:00
Vincent Composieux
16a980b937 [Validator] Fix bug order for constraint, property, getter and group-sequence-provider in validation.xml 2012-07-19 20:43:09 +02:00
Victor Berchet
ed8823c168 [HttpFoundation] Allow setting an unknown status code without specifying a text 2012-07-19 17:48:12 +02:00
Klein Florian
db9ea095f0 [Doctrine] [Bridge] fix repositoryMethod test 2012-07-19 16:54:35 +02:00
Fabien Potencier
67bf84d7c5 [Routing] fixed typo 2012-07-19 16:39:03 +02:00
Klein Florian
2a6c222c51 Add a customRepository option to the uniqueEntity validator 2012-07-19 16:24:10 +02:00
Fabien Potencier
42f1f12ec5 merged branch mpiecko/patch-1 (PR #4977)
Commits
-------

f5e03a3 Changed $request->setDefaultLocale() to $request->setLocale() in custom LocaleListener.

Discussion
----------

Changed $request->setDefaultLocale() to $request->setLocale() in custom ...

...LocaleListener.

---------------------------------------------------------------------------

by mpiecko at 2012-07-19T13:05:07Z

This is based on my comments from https://github.com/symfony/symfony/pull/4692#issuecomment-7096255
2012-07-19 15:10:58 +02:00
Michael Piecko
f5e03a3716 Changed $request->setDefaultLocale() to $request->setLocale() in custom LocaleListener. 2012-07-19 15:48:21 +03:00
Fabien Potencier
382f8a5eb9 merged branch Tobion/patch-2 (PR #4968)
Commits
-------

1986e10 [HttpFoundation] optimize makeDisposition

Discussion
----------

[HttpFoundation] optimize makeDisposition
2012-07-19 11:21:09 +02:00
Fabien Potencier
d5463acb23 merged branch cs278/rhel5-invalid-exitcode (PR #4970)
Commits
-------

310c458 [Process] Fixed a problem on RHEL5 where the exit code was incorrect

Discussion
----------

[Process] Fixed a problem on RHEL5 where the exit code was incorrect

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT

RHEL5 will intermittently result in an exit code of -1 due to `proc_get_status()` being called after the process has completed but outside of `updateStatus()` which saves the exit code.

See composer/composer#876
2012-07-19 10:06:46 +02:00
Fabien Potencier
f53c4ba1e5 merged branch pborreli/profiler-pixel (PR #4969)
Commits
-------

3bb975c [WebProfilerBundle] Fixed white pixel in toolbar info

Discussion
----------

[WebProfilerBundle] Fixed white pixel in toolbar info

Fixed this ![white pixel](http://www7.pic-upload.de/18.07.12/l7ve9xrevwc.png)

Tested on IE9/FF/Chrome
2012-07-18 19:56:21 +02:00
Chris Smith
310c458936 [Process] Fixed a problem on RHEL5 where the exit code was incorrect
RHEL5 will intermittently result in an exit code of -1 [1] due to
proc_get_status() being called after the process has completed
but outside of updateStatus() which saves the exit code.

[1]: https://github.com/composer/composer/issues/876
2012-07-18 18:33:32 +01:00
Pascal Borreli
3bb975c153 [WebProfilerBundle] Fixed white pixel in toolbar info 2012-07-18 19:29:43 +02:00
Tobias Schultze
1986e1052a [HttpFoundation] optimize makeDisposition 2012-07-18 18:28:33 +03:00
Fabien Potencier
cb82287416 merged branch weaverryan/upgrade-listener-priorities (PR #4928)
Commits
-------

96638f4 [UPGRADE] Tweaking formatting error with event listener section. Also tweaking values

Discussion
----------

[UPGRADE] Tweaking formatting error with event listener section and information

Hey guys!

This is just a documentation change based on sha: 5da1bc6a4f

Check out the details in the commit message - I'm not sure if this is right, but the original commit seemed a bit odd compared to what I was seeing in the code. There was also a fix to the formatting.

If I've missed something, I'm happy to change the commit as needed.

Thanks!

---------------------------------------------------------------------------

by stof at 2012-07-14T21:53:12Z

There is no equivalent to early_kernel_request for the router listener as both methods have been merged together (it was separated so that the initialization of the RequestContext was done before the firewall, but the whole logic is before the firewall now)
2012-07-18 17:00:08 +02:00
Fabien Potencier
ec5fee0cbb merged branch biozshock/more-verbose-message-form-getname (PR #4940)
Commits
-------

89975ef Added more verbose message for exception when form types have wrong getName method

Discussion
----------

Added more verbose message for exception when form types have wrong getName

PR based on discussion of commit introduces exception when custom form type have no getName method. 6489a65960

---------------------------------------------------------------------------

by biozshock at 2012-07-17T08:15:35Z

@tyx thanks. Fixed. ;)

---------------------------------------------------------------------------

by fabpot at 2012-07-17T20:46:57Z

Can you squash your commits before I merge? Thanks.

---------------------------------------------------------------------------

by noetix at 2012-07-17T23:49:51Z

I think the variables should have quotes around them. It seems like all other error messages have them.

From: The type name specified for the service form.type.translatable does not match the actual name. Expected translatable_field, given translator

To: The type name specified for the service "form.type.translatable" does not match the actual name. Expected "translatable_field", given "translator"

---------------------------------------------------------------------------

by biozshock at 2012-07-18T09:39:01Z

@fabpot Done.
@noetix Thanks for remark.
2012-07-18 14:45:41 +02:00
Artem Lopata (bumz)
89975ef9d6 Added more verbose message for exception when form types have wrong getName method 2012-07-18 12:37:22 +03:00
Fabien Potencier
4ce724936a moved the request data collector to HttpKernel 2012-07-18 10:39:53 +02:00
Fabien Potencier
a7503fb399 added a missing comment 2012-07-18 10:24:35 +02:00
Fabien Potencier
ebea32c40d merged branch guilhermeblanco/patch-9 (PR #4949)
Commits
-------

1f33756 Update master

Discussion
----------

Allow HttpKernel ->render to be called directly

Hi,

I faced this problem in a funny situation.
Working on tests of individual components, I want to be able to test sub-requests. These elements are not mapped directly, relying on `FrameworkBundle` routing internal to achieve its goal.

The nature of my application leads to fully decoupled bundles, being a website responsible to define everything, from app configuration to routing elements. That way, an individual bundle controller don't know the route it should call, leading the test to be harder to do.

Together with this situation, it is also required in my testing scenario to be able to test the real world execution, then being an ESI include (a sub-request). This test then needs to be able to directly call controller to be rendered. That said, `HttpKernel` provides an API that does exactly what is required to achieve my goal, calling `render()` which triggers the sub-request and also accepts options which allows me to test the real world scenarios.
But as soon as you trigger the method, `ProfileListener` intercepts the kernel response to collect profiling information. Under this specific situation, since you called directly `render`, there's no master request, then leading the test to fail with the following PHP warning:

```
Warning: SplObjectStorage::offsetExists() expects parameter 1 to be object, boolean given in /var/www/nde/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/EventListener/ProfilerListener.php line 120
```

To fix that, all that is needed is a check for a possible parent request. That's the purpose of this patch. =)

---------------------------------------------------------------------------

by stof at 2012-07-17T15:11:13Z

This looks good to me, but as said on IRC, a test should be added to avoid regressions
2012-07-18 10:22:46 +02:00
Fabien Potencier
f6815be7f2 [FrameworkBundle] raised the max nesting level for XDebug for tests to pass 2012-07-18 10:19:41 +02:00
Fabien Potencier
e0409f5218 fixed some tests 2012-07-18 10:08:52 +02:00
Fabien Potencier
0598043cef removed unneeded echo 2012-07-18 09:46:34 +02:00
Fabien Potencier
1570db9646 merged branch bschussek/performance (PR #4918)
Commits
-------

1474aa5 [Form] Fixed consideration of Twig's template inheritance and added another performance-improving check
b4ec7f5 Fixed my rubbish English
d11f8b5 [Form] Fixed passing of variables in the FormRenderer
629093e [Form] Extracted common parts of FormHelper and FormExtension into separate classes
216c539 [Form] Implemented a more intelligent caching strategy in FormHelper (PHP +100ms, Twig +100ms)

Discussion
----------

[Form] Merged FormHelper and FormExtension and implemented a better caching strategy

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -

This PR extracts common parts of `FormHelper` and `FormExtension` into implementations of the new interfaces `FormRendererInterface` and `FormRendererEngineInterface`. The implemented `AbstractRendererEngine` features a more intelligent caching strategy than the one used before. When this strategy was implemented directly in `FormHelper`, the performance of [this specific, heavy form](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1) could be improved from **2.5** to **2.25 seconds** on my machine for PHP templates.

Due to the abstraction and delegation, the performance gain is not that big anymore, but we still have a performance gain of about **0.1 seconds** for both PHP and Twig in the above example. The second, big improvement of this PR is maintainability - the differences between PHP and Twig templates are now contained in relatively small classes - and extendability (it is very easy now to support different template engines).

---------------------------------------------------------------------------

by stof at 2012-07-14T13:47:19Z

should a similar refactoring be done for the [Twig rendering](https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Extension/FormExtension.php) ?

---------------------------------------------------------------------------

by bschussek at 2012-07-14T13:49:25Z

Yes. I would like to merge the common parts of Twig's FormExtension and PHP's FormHelper into an abstract class. Before that I need to have a [working, heavy Twig Form](https://twitter.com/webmozart/status/224135287377371138) in order to measure whether I don't actually decrease the performance with Twig. Can you help me there?

---------------------------------------------------------------------------

by vicb at 2012-07-16T21:48:24Z

Would it make sense to create a 'renderer' folder in the form component and move related classes there ?

---------------------------------------------------------------------------

by stof at 2012-07-16T22:06:58Z

@vicb It makes sense to keep the Twig renderer in the brisge. This is what the bridge is about. Moving the Twig class to the component would not be consistent. And the PHP renderer is already in the component (but it could make sense to move the helper from FrameworkBundle to the TemplatingExtension of the Form component though)

---------------------------------------------------------------------------

by vicb at 2012-07-16T22:16:50Z

@stof I was only referring to the classes located in the Component/Form folder.

---------------------------------------------------------------------------

by vicb at 2012-07-16T22:27:27Z

Overall I don't really know what to think of this PR. PHP and Twig use a different way to support blocks:

- PHP has one block per file,
- Twig could have many blocks per templates.

I am not sure if this PR is optimal for Twig and improves maintainability ?

---------------------------------------------------------------------------

by stof at 2012-07-16T22:46:11Z

@vicb it avoids duplicating the whole rendering logic for each engine (there is at least a third one in [SmartyBundle](https://github.com/noiselabs/SmartyBundle/blob/master/Extension/FormExtension.php) btw)

---------------------------------------------------------------------------

by bschussek at 2012-07-17T07:16:42Z

@vicb I don't think a renderer subfolder makes sense. The interfaces belong to the main namespace, and then the subfolder would only contain two classes.

Considering maintainability for Twig, I think that this PR in fact increases it. TwigExtension before always had to check the whole type hierarchy, while now the code in AbstractRendererEngine makes sure that this process is speeded up.

Before:
```
load _some_entity_field_label:
    - check _some_entity_field_label
    - check entity_label
    - check choice_label
    - check form_label

load _some_other_entity_field_label
    - check _some_other_entity_field_label
    - check entity_label
    - check choice_label
    - check form_label

a.s.o.
```

After:
```
load _some_entity_field_label:
    - check _some_entity_field_label
    - check entity_label (hits the cache if entity_label was checked before)
    - check choice_label (hits the cache if choice_label was checked before)
    - check form_label

load _some_other_entity_field_label
    - check _some_other_entity_field_label
    - check entity_label (now definitely hits the cache)

a.s.o.
```

Since many fields share the same ancestors in the inheritance tree, this definitely improves performance.

As can also be deducted here, custom block names such as `_some_entity_field_label` are now a major drawback. There is nothing we can cache for them, so they need to be checked for every individual block that we load. Removing this feature surprisingly gains no performance for Twig (I need to investigate why at some point), but it speeds up rendering for **250ms** using the PHP engine on [this example form](advancedform.gpserver.dk/app_dev.php/taxclasses/1), dropping the rendering time from 1.25 to 1 sec on my local machine. I'm not sure what we should do here.

---------------------------------------------------------------------------

by stof at 2012-07-17T07:21:31Z

@bschussek could it be possible to have an implementation checking the custom block and another one skipping it ? This way, the user could disable this feature when he does not need it.

---------------------------------------------------------------------------

by bschussek at 2012-07-17T07:38:34Z

@stof It would be possible to add a switch to `FormRenderer` that controls whether custom blocks are checked or not.

If this switch is disabled by default, we break BC. If this switch is enabled by default, it will be pretty useless. People will start designing away for custom blocks, and once they want to improve performance, they can't turn off the switch anymore because it would require too many changes.

---------------------------------------------------------------------------

by stof at 2012-07-17T08:08:38Z

@fabpot what do you think about it ?

---------------------------------------------------------------------------

by bschussek at 2012-07-17T08:41:43Z

Another option that just came to mind is to remove inheritance checks for anything but _widget and _row. I.e., if we render `entity_widget`, check
```
_id_widget
entity_widget
choice_widget
form_widget
```
But if we render `entity_label`, only check
```
_id_label
form_label
```

This improves PHP Templating for **170ms** and Twig for **20ms**. We gain another **150ms** for PHP Templating and **~15ms** for Twig if we also restrict custom fields (_id_widget) to the _widget and _row suffixes (it's really hard to tweak the renderer for Twig.. I think a lot of its performance bottlenecks lie in Twig itself).

Do you have any data on how often blocks other than _widget and _row are customized for specific types/IDs?

---------------------------------------------------------------------------

by stof at 2012-07-17T09:47:38Z

Well, I think most of the time other blocks are not even customized based on the type :)

---------------------------------------------------------------------------

by Tobion at 2012-07-17T14:32:39Z

From my experience rendering the form components individually is easier and more flexible than customizing by ID or type.
But there are still use cases for customizing like library-like bundles (e.g. Bootstrap).
2012-07-18 08:33:15 +02:00
Fabien Potencier
ddaa591f72 merged branch Tobion/patch-1 (PR #4959)
Commits
-------

5233984 fix class name in upgrade

Discussion
----------

fix class name in upgrade
2012-07-18 07:57:22 +02:00
Tobias Schultze
5233984ec0 fix class name in upgrade 2012-07-18 07:53:58 +03:00
Fabien Potencier
242a388ea4 merged branch bschussek/optionsresolver (PR #4945)
Commits
-------

610c602 [OptionsResolver] Slightly tweaked the performance of the Options class

Discussion
----------

[OptionsResolver] Slightly tweaked the performance of the Options class

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
2012-07-17 23:06:01 +02:00
Fabien Potencier
34c2bf75e0 merged branch bschussek/phpengine_cache_escape (PR #4942)
Commits
-------

0d0a968 [Templating] Cached the result of escape() in order to improve performance (+470ms)

Discussion
----------

[Templating] Cached the result of escape() in order to improve performance

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -

This improvement gains **400ms** of rendering speed on [this particular example page](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1).

---------------------------------------------------------------------------

by lsmith77 at 2012-07-16T17:36:50Z

i guess we don't have to be concerned with increased memory usage here .. if at all we could offer a clear cache method in case someone is f.e. using this to generate tons of messages in a cron job.

---------------------------------------------------------------------------

by henrikbjorn at 2012-07-17T06:39:52Z

The example form is broken.

---------------------------------------------------------------------------

by bschussek at 2012-07-17T07:21:26Z

The source code for the form can be found [here](https://github.com/stof/symfony-standard/blob/twig_forms/src/AdvancedForm/CoreBundle/Form/TaxClassType.php).

---------------------------------------------------------------------------

by henrikbjorn at 2012-07-17T07:28:11Z

But i am guessing this is only for php not twig :P

---------------------------------------------------------------------------

by bschussek at 2012-07-17T07:41:07Z

Obviously..
2012-07-17 22:45:12 +02:00
Fabien Potencier
8754c0c33f merged branch stof/doctrine_2_3 (PR #4941)
Commits
-------

8f99be3 [DoctrineBridge] Fixed the type guesser for doctrine 2.3

Discussion
----------

[DoctrineBridge] Fixed the type guesser for doctrine 2.3

Doctrine 2.3 now uses the drivers moved to Common, so the exception was not catched anymore and was breaking the guessing when a non-entity was used.

---------------------------------------------------------------------------

by craue at 2012-07-16T14:54:30Z

👍

---------------------------------------------------------------------------

by ddeboer at 2012-07-17T20:07:57Z

👍

---------------------------------------------------------------------------

by stof at 2012-07-17T20:17:01Z

@fabpot please merge this as 2.1 is currently broken when you rely on the form guessers for unmapped classes
2012-07-17 22:45:07 +02:00
Fabien Potencier
f52ce61782 merged branch bschussek/issue4125 (PR #4953)
Commits
-------

17ca9b6 [Form] Fixed DoctrineType to use getManagerForClass() if no EM name is given

Discussion
----------

[Form] Fixed DoctrineType to use getManagerForClass() if no EM name is given

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4125
Todo: -

---------------------------------------------------------------------------

by stof at 2012-07-17T08:16:59Z

👍
2012-07-17 11:07:53 +02:00
Fabien Potencier
0f746a5a66 merged branch jonathaningram/patch-7 (PR #4950)
Commits
-------

764b1de [FrameworkBundle] minor typo in controller action docblock

Discussion
----------

[FrameworkBundle] minor typo in controller action docblock
2012-07-17 10:32:57 +02:00