Skip to content
This repository

Apr 02, 2013

  1. Dariusz Górecki

    [CS Fix] Consistent coding-style of concatenation operator usage

    authored

Nov 29, 2012

  1. Fabien Potencier

    Merge branch '2.1'

    * 2.1: (29 commits)
      [DependencyInjection] fixed composer.json
      [Validator] Fix typos in validators.ru.xlf
      Edited some minor grammar and style errors in russian validation file
      Updated Bulgarian translation
      [Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
      [Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
      [Form] simplified a test from previous merge
      Update src/Symfony/Component/Form/Extension/Core/Type/FileType.php
      fixed CS
      Xliff with other node than source or target are ignored
      small fix of #5984 when the container param is not set
      Filesystem Component mirror symlinked directory fix
      [Process][Tests] fixed chainedCommandsOutput tests
      fixed CS
      Use better default ports in urlRedirectAction
      Add tests for urlRedirectAction
      info about session namespace
      fix upgrade info about locale
      Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
      Update src/Symfony/Component/DomCrawler/Form.php
      ...
    authored

Nov 19, 2012

  1. Tobias Schultze

    info about session namespace

    authored
  2. Tobias Schultze

    fix upgrade info about locale

    it duplicated the header and had an irrelevant point inbetween
    authored

Nov 07, 2012

  1. Moritz Borgmann

    Update UPGRADE-2.1.md

    Change on selectedchoice part, because "choice.value" wont work, but just "value" does.
    authored

Oct 25, 2012

  1. Grégoire Paris

    Remove § about prototype_name customization in 2.0

    I don't think this was even possible in 2.0
    authored
  2. Grégoire Paris

    fix option name

    authored

Oct 19, 2012

  1. Peter Kruithof

    Documented removed _form_is_choice_group function

    Also changed for-loop variables to match the current `form_div_layout.html.twig` code.
    authored

Oct 16, 2012

  1. Florent Cailhol

    Fix typo

    authored fabpot committed

Sep 19, 2012

  1. Kevin McBride

    Fixed FlashBagInterface phpdoc, clarified UPGRADE docs

    authored

Sep 04, 2012

  1. Thomas Tourlourat

    Remove "you" word.

    authored

Aug 22, 2012

  1. Johannes

    added note about 404 error pages

    authored

Aug 16, 2012

  1. Fabien Potencier

    fixed typos in the UPGRADE file

    authored
  2. Fabien Potencier

    merged branch TomAdam/pr-choice-bc-doc (PR #5263)

    Commits
    -------
    
    9e3e589 Alter upgrade notes with changes to _form_is_choice_selected twig function
    
    Discussion
    ----------
    
    Undocumented BC break - choice field type template
    
    The upgrade notes for the choice field template are out of date. They currently state:
    
    ```
    The `choices` variable now contains `ChoiceView` objects with two getters,
    getValue() and getLabel(), to access the choice data.
    ```
    
    However these methods do not exist. I assume this is the result of a rollback to maintain BC?
    
    In addition to this, the `_form_is_choice_selected` twig function has been removed and replaced with a filter called `selectedchoice`. This is an undocumented BC break. I have attached an update to the notes to reflect these changes.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-08-15T17:20:35Z
    
    ping @bschussek
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-08-16T17:36:22Z
    
    Looks good apart from my comment. Thanks for fixing this!
    authored
  3. Fabien Potencier

    fixed typo in the UPGRADE file

    authored
  4. Tiago Ribeiro

    Typo in UPGRADE-2.1

    authored

Aug 14, 2012

  1. Tom Adam

    Alter upgrade notes with changes to _form_is_choice_selected twig fun…

    …ction
    authored

Aug 02, 2012

  1. Richard Miller

    Added before/after examples of change in registering security factori…

    …es to upgrade info.
    authored

Jul 30, 2012

  1. Bernhard Schussek

    [Validator] Added entry point "Validation" for more convenient usage …

    …outside of Symfony2
    authored

Jul 29, 2012

  1. Bernhard Schussek

    [Form] Fixed ResolvedFormType to really be replaceable

    authored

Jul 26, 2012

  1. [FrameworkBundle] Switched to parameters for request context host and…

    … scheme
    authored

Jul 23, 2012

  1. Tobias Schultze

    remove relict in upgrade

    authored

Jul 22, 2012

  1. Bernhard Schussek

    [Form] Improved FormRenderer API to reduce the size of the function c…

    …all stack during rendering
    authored

Jul 21, 2012

  1. Bernhard Schussek

    [Form] Added a layer of 2.0 BC methods to FormView and updated UPGRAD…

    …E and CHANGELOG
    authored

Jul 19, 2012

  1. Changed $request->setDefaultLocale() to $request->setLocale() in cust…

    …om LocaleListener.
    authored

Jul 18, 2012

  1. Fabien Potencier

    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: 5da1bc6
    
    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)
    authored
  2. Fabien Potencier

    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).
    authored
  3. Tobias Schultze

    fix class name in upgrade

    authored

Jul 16, 2012

  1. Bernhard Schussek

    [Form] Extracted common parts of FormHelper and FormExtension into se…

    …parate classes
    authored

Jul 14, 2012

  1. Ryan Weaver

    [UPGRADE] Tweaking formatting error with event listener section. Also…

    … tweaking values
    
    Some of the values here are either wrong, or are drawing their logic from an area I can't find. I've used the following logic for this change:
    
    * security.firewall - this is easy, it just changed
    
    * locale listener - this didn't exist in Symfony 2.0, but it was done on the RouterListener::onKernelRequest(), which had a priority of 0. The new listener has a priority of 16
    
    * The early request router listener is gone - I'm not sure it has an equivalent
    
    * The RouterListener priority changed from 0 to 32
    authored
  2. Bernhard Schussek

    [Form] Individual rows of CollectionType cannot be styled anymore for…

    … performance reasons
    authored

Jul 13, 2012

  1. Bernhard Schussek

    [Form] Cached the form type hierarchy in order to improve performance

    authored

Jul 11, 2012

  1. Bernhard Schussek

    [Validator] Added Length constraint and deprecated MinLength and MaxL…

    …ength
    authored
  2. Bernhard Schussek

    [Validator] Deprecated the constraints Min and Max in favor of Range

    authored
  3. Bernhard Schussek

    [Validator] Deprecated the Size constraint

    authored
Something went wrong with that request. Please try again.