Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Sep 13, 2013
  1. @fabpot
Commits on Mar 6, 2013
  1. @WouterJ

    Fixed typo in UPGRADE-2.2

    WouterJ authored
Commits on Feb 4, 2013
  1. @hhamon

    [Security] renamed Constraint namespace to Constraints for validator …

    hhamon authored
    …classes in order to be consistent with the whole current validator API.
Commits on Jan 28, 2013
  1. @lyrixx

    Updated UPGRADE-2.2.md for twig bridge section

    lyrixx authored
    | Q             | A
    | ------------- | ---
    | Bug fix?      | yes
    | New feature?  | no
    | BC breaks?    | no
    | Deprecations? | no
    | Tests pass?   | yes
    | Fixed tickets | -
    | License       | MIT
    | Doc PR        | -
Commits on Jan 19, 2013
  1. @fabpot

    fixed markup

    fabpot authored
  2. @fabpot

    merged branch beberlei/SerializerOptions (PR #6797)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    fcabadf Fix JsonDecode to work on PHP 5.3, update the CHANGELOG.md
    b6bdb45 Completly refactor the Serializer Options Pull Request to push context information directly and avoid state and dependencies between SerializerInterface and encoders/normalizers.
    ef652e2 Added context to JsonEncoder
    eacb7e2 Rename $options to $context, as it makes the intent much more clear.
    8854b85 Fix CS issues, removed global options
    9c54a4b [Serializer] Allow options to be passed to SerialiizerInterface#serialize and #unserialize. Thsee options are available to all encoders/decoders/normalizers that implement SerializerAwareInterface.
    
    Discussion
    ----------
    
    [2.2] [Serializer] Configurable Serializer
    
    Bug fix: no
    Feature addition: yes
    Backwards compatibility break: yes
    Symfony2 tests pass: yes
    Fixes the following tickets: #4907, #4938
    License of the code: MIT
    Todo:
    
    This is an extension of GH-6574 that removes the context state in favor of passing this information around.
    
    ---------------------------------------------------------------------------
    
    by beberlei at 2013-01-18T13:12:39Z
    
    @fabpot @lsmith I think this is how it should work from an OOP/OOD perpesctive, avoiding the context state. This makes for a much cleaner code and dependency graph.
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2013-01-18T14:14:37Z
    
    makes sense. anything fancier would lose this components simplicity which IMHO is the main benefit versus JMS serializer.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-18T14:26:25Z
    
    Looks very good. :+1:
    
    ---------------------------------------------------------------------------
    
    by beberlei at 2013-01-18T14:37:32Z
    
    I need to fix the failures with the JsonEncoder and then this is good to merge
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-18T14:40:21Z
    
    you also need to update the CHANGELOG of the component
    
    ---------------------------------------------------------------------------
    
    by beberlei at 2013-01-18T23:17:57Z
    
    Fixed, only the Redis Profiler problem still failing the Travis builds. Also I updated the CHANGELOG.md.
    
    @fabpot  Good to merge from my POV
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-18T23:27:59Z
    
    @beberlei see #6804 for the Redis profiler issue
Commits on Jan 18, 2013
  1. @beberlei

    Completly refactor the Serializer Options Pull Request to push contex…

    beberlei authored
    …t information directly and avoid state and dependencies between SerializerInterface and encoders/normalizers.
Commits on Jan 15, 2013
  1. @kriswallsmith

    fixed typo

    kriswallsmith authored
Commits on Jan 11, 2013
  1. @fabpot

    merged branch fabpot/kernel-refactor (PR #6459)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    76fefe3 updated CHANGELOG and UPGRADE files
    f7da1f0 added some unit tests (and fixed some bugs)
    f17f586 moved the container aware HTTP kernel to the HttpKernel component
    2eea768 moved the deprecation logic calls outside the new HttpContentRenderer class
    bd102c5 made the content renderer work even when ESI is disabled or when no templating engine is available (the latter being mostly useful when testing)
    a8ea4e4 [FrameworkBundle] deprecated HttpKernel::forward() (it is only used once now and not part of any interface anyway)
    1240690 [HttpKernel] made the strategy a regular parameter in HttpContentRenderer::render()
    adc067e [FrameworkBundle] made some services private
    1f1392d [HttpKernel] simplified and enhanced code managing the hinclude strategy
    403bb06 [HttpKernel] added missing phpdoc and tweaked existing ones
    892f00f [HttpKernel] added a URL signer mechanism for hincludes
    a0c49c3 [TwigBridge] added a render_* function to ease usage of custom rendering strategies
    9aaceb1 moved the logic from HttpKernel in FrameworkBundle to the HttpKernel component
    
    Discussion
    ----------
    
    [WIP] Kernel refactor
    
    Currently, the handling of sub-requests (including ESI and hinclude) is mostly done in FrameworkBundle. It makes these important features harder to implement for people using only HttpKernel (like Drupal and Silex for instance).
    
    This PR moves the code to HttpKernel instead. The code has also been refactored to allow easier integration of other rendering strategies (refs #6108).
    
    The internal route has been re-introduced but it can only be used for trusted IPs (so for the internal rendering which is managed by Symfony itself, or by a trusted reverse proxy like Varnish for ESI handling). For the hinclude strategy, when using a controller, the URL is automatically signed (see #6463).
    
    The usage of a listener instead of a controller to handle internal sub-requests speeds up things quite a lot as it saves one sub-request handling. In Symfony 2.0 and 2.1, the handling of a sub-request actually creates two sub-requests.
    
    Rendering a sub-request from a controller can be done with the following code:
    
    ```jinja
    {# default strategy #}
    {{ render(path("partial")) }}
    {{ render(controller("SomeBundle:Controller:partial")) }}
    
    {# ESI strategy #}
    {{ render(path("partial"), { strategy: 'esi' }) }}
    {{ render(controller("SomeBundle:Controller:partial"), { strategy: 'esi' }) }}
    
    {# hinclude strategy #}
    {{ render(path("default1"), { strategy: 'hinclude' }) }}
    ```
    
    The second commit allows to simplify the calls a little bit thanks to some nice syntactic sugar:
    
    ```jinja
    {# default strategy #}
    {{ render(path("partial")) }}
    {{ render(controller("SomeBundle:Controller:partial")) }}
    
    {# ESI strategy #}
    {{ render_esi(path("partial")) }}
    {{ render_esi(controller("SomeBundle:Controller:partial")) }}
    
    {# hinclude strategy #}
    {{ render_hinclude(path("default1")) }}
    ```
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-03T17:58:49Z
    
    I've just pushed a new version of the code that actually works in my browser (but I've not yet written any unit tests). I've updated the PR description accordingly.
    
    All comments welcome!
    
    ---------------------------------------------------------------------------
    
    by Koc at 2013-01-03T20:11:43Z
    
    what about `render(controller="SomeBundle:Controller:partial", strategy="esi")`?
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-04T09:01:01Z
    
    shouldn't we have interfaces for the UriSigner and the HttpContentRenderer ?
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2013-01-04T19:28:09Z
    
    btw .. as mentioned in #6213 i think it would make sense to refactor the HttpCache to use a cache layer to allow more flexibility in where to cache the data (including clustering) and better invalidation. as such if you are refactoring HttpKernel .. it might also make sense to explore splitting off HttpCache.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-04T19:30:07Z
    
    @lsmith77 This is a totally different topic. This PR is just about moving things from FrameworkBundle to HttpKernel to make them more reusable outside of the full-stack framework.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-05T09:39:52Z
    
    I think this PR is almost ready now. I still need to update the docs and add some unit tests. Any other comments on the whole approach? The class names? The `controller` function thingy? The URI signer mechanism? The proxy protection for the internal controller? The proxy to handle internal routes?
    
    ---------------------------------------------------------------------------
    
    by sstok at 2013-01-05T10:08:25Z
    
    Looks good to me :+1:
    
    ---------------------------------------------------------------------------
    
    by sdboyer at 2013-01-07T18:17:08Z
    
    @Crell asked me to weigh in, since i'm one of the Drupal folks who's likely to work most with this.
    
    i think i've grokked about 60% of the big picture here, and i'm generally happy with what i see. the assumption that the HInclude strategy makes about working with templates probably isn't one that we'll be able to use (and so, would need to write our own), but that's not a big deal since the whole goal here is to make strategies pluggable.
    
    so, yeah. +1.
    
    ---------------------------------------------------------------------------
    
    by winzou at 2013-01-09T20:21:44Z
    
    Just for my information: will this PR be merged for 2.2 version? Thanks.
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-09T20:41:04Z
    
    @winzou according to the blog post announcing the beta 1 release, yes. It is explicitly listed as being one of the reason to make it a beta instead of the first RC.
    
    ---------------------------------------------------------------------------
    
    by winzou at 2013-01-09T20:49:36Z
    
    OK thanks, I've totally skipped this blog post.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-10T15:26:15Z
    
    I've just added a bunch of unit tests and fix some bugs I found while writing the tests.
Commits on Jan 10, 2013
  1. @fabpot
  2. @webmozart
Commits on Jan 8, 2013
  1. @webmozart

    [Validator] Changed validator to support pluralized messages by default

    webmozart authored
    This was implemented in order to satisfy Drupal's requirements for a
    singular and a plural message whenever a message is passed to their
    implementation of transChoice().
  2. @webmozart
Commits on Jan 7, 2013
  1. @webmozart

    [Form] Protected methods in FormConfigBuilder and FormBuilder from be…

    webmozart authored
    …ing called when it is turned into a FormConfigInterface instance
Commits on Dec 29, 2012
  1. @fabpot

    Revert "merged branch ricardclau/rename_choice_to_oneof (PR #6360)"

    fabpot authored
    This reverts commit 1de60c9, reversing
    changes made to e3cc337.
    
    Conflicts:
    	UPGRADE-2.2.md
Commits on Dec 20, 2012
  1. @fabpot
  2. @fabpot

    tweaked previous merge

    fabpot authored
  3. @benja-M-1
  4. @fabpot
Commits on Dec 18, 2012
  1. @webmozart
Commits on Dec 15, 2012
  1. @ricardclau

    create oneof constraint and add deprecation messages in choice, also …

    ricardclau authored
    …make choice extend new oneOf constraint to avoid duplicate code
Commits on Dec 11, 2012
  1. @Tobion @fabpot

    [Routing] clean up of RouteCollection API

    Tobion authored fabpot committed
Commits on Dec 5, 2012
  1. @fabpot

    merged branch Tobion/collection-flat (PR #6120)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    51223c0 added upgrade instructions
    50e6259 adjusted tests
    98f3ca8 [Routing] removed tree structure from RouteCollection
    
    Discussion
    ----------
    
    [Routing] removed tree structure from RouteCollection
    
    BC break: yes (see below)
    Deprecations: RouteCollection::getParent(); RouteCollection::getRoot()
    tests pass: yes
    
    The reason for this is so quite simple. The RouteCollection has been designed as a tree structure, but it cannot at all be used as one. There is no getter for a sub-collection at all. So you cannot access a sub-collection after you added it to the tree with `addCollection(new RouteCollection())`. In contrast to the form component, e.g. `$form->get('child')->get('grandchild')`.
    So you can see the RouteCollection cannot be used as a tree and it should not, as the same can be achieved with a flat array!
    Using a flat array removes all the need for recursive traversal and makes the code much faster, much lighter, less memory (big problem in CMS with many routes) and less error-prone.
    
    BC break: there is only a BC break if somebody used the PHP API for defining RouteCollection and also added a Route to a collection after it has been added to another collection.
    So
    ```
    $rootCollection = new RouteCollection();
    $subCollection = new RouteCollection();
    $rootCollection->addCollection($subCollection);
    $subCollection->add('foo', new Route('/foo'));
    ```
    must be updated to the following (otherwise the 'foo' Route is not imported to the rootCollection)
    ```
    $rootCollection = new RouteCollection();
    $subCollection = new RouteCollection();
    $subCollection->add('foo', new Route('/foo'));
    $rootCollection->addCollection($subCollection);
    ```
    
    Also one must call addCollection from the bottom to the top. So the correct sequence is the following (and not the reverse)
    ```
    $childCollection->->addCollection($grandchildCollection);
    $rootCollection->addCollection($childCollection);
    ```
    
    Remeber, this is only needed when using PHP for defining routes and calling methods in a special order. There is no change required when using XML or YAML for definitions. Also, I'm pretty sure that neither the CMF, nor Drupal routing, nor Silex is relying on the tree stuff. So they should also still work.
    
    cc @fabpot @crell @dbu
    
    One more thing: RouteCollection wasn't an appropriate name for a tree anyway as a collection of routes (that it now is) is definitely not a tree.
    Yet another point: The XML declaration of routes uses the `<import>` element, which is excatly what the new implementation of addCollection without the need of a tree does. So this is now also more analogous.
    
    ---------------------------------------------------------------------------
    
    by Koc at 2012-11-26T17:34:15Z
    
    What benefit of this?
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-11-26T17:56:53Z
    
    @Koc Why did you not simply wait for the description? ^^
    
    ---------------------------------------------------------------------------
    
    by dbu at 2012-11-26T18:33:09Z
    
    i love PR that remove more code than they add whithout removing functionality.
    
    ---------------------------------------------------------------------------
    
    by Crell at 2012-11-26T18:49:52Z
    
    There's an issue somewhere in Drupal where we're trying to use addCollection() as a shorthand for iterating over one collection and calling add() on the other for each item.  We can't do that, however, because the subcollections are not flattened properly when reading back and our current dumper can't cope with that.  So this change would not harm Drupal at all, and would mean I don't have fix a bug in our dumper. :-)  I cannot speak for any other projects, of course.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-11-27T19:06:34Z
    
    Ok, this is ready.
Commits on Nov 28, 2012
  1. @fabpot

    [HttpFoundation] disabled Request _method feature by default (should …

    fabpot authored
    …now be explicitely enabled via a call to enableHttpMethodOverride())
Commits on Nov 27, 2012
  1. @Tobion

    added upgrade instructions

    Tobion authored
Commits on Nov 26, 2012
  1. @ragtek

    Update UPGRADE-2.2.md

    ragtek authored
    fixed typo
Commits on Nov 25, 2012
  1. @fabpot

    fixed typo

    fabpot authored
Commits on Nov 24, 2012
  1. @webmozart
Commits on Nov 16, 2012
  1. @egeloen
Commits on Nov 10, 2012
  1. @dlsniper
Commits on Nov 6, 2012
  1. @jmikola
Commits on Nov 5, 2012
  1. @jfsimon @fabpot

    [http-foudation] Better accept header parsing

    jfsimon authored fabpot committed
Something went wrong with that request. Please try again.