Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Dec 17, 2011
  1. @fabpot
  2. @fabpot

    Merge branch '2.0'

    fabpot authored
    * 2.0:
      fixed functional tests so that the cache/logs are specific to one version of Symfony (to avoid weird side effects)
      [FrameworkBundle] Prove client insulation and non-insulation works in session tests.
      [FrameworkBundle] Add tests to prove functional testing works with simultaneous clients.
      [FrameworkBundle] Small changes to test setup.
      [DoctrineBundle] Fixed incorrectly shown params
      [SwiftmailerBundle] fixed the send email command when the queue does not extends Swift_ConfigurableSpool
  3. @fabpot

    fixed functional tests so that the cache/logs are specific to one ver…

    fabpot authored
    …sion of Symfony (to avoid weird side effects)
  4. @fabpot

    fixed typo

    fabpot authored
  5. @fabpot

    merged branch stof/doctrine_profiling (PR #2895)

    fabpot authored
    Commits
    -------
    
    8713c2d [DoctrineBridge][DoctrineBundle] Refactored the DBAL logging
    
    Discussion
    ----------
    
    [DoctrineBridge][DoctrineBundle] Refactored the DBAL logging
    
    This allows enabling the logging and the profiling separately. This is useful for instance when doing batch processing leading to memory issue because of the profiling. In such case, the only solution currently is to disable the logging totally whereas disabling only the use of the profiler would allow seeing the queries in the logs (and the profiles are not collected in the CLI anyway).
    
    I'm not sure about the place where the ``Stopwatch`` should be used. Keeping it in the ``DbalLogger`` with Monolog was the easy way as it allows using the DBAL class directly to collect queries for the profiler but technically the ``Stopwatch`` is used by the profiler.
    
    the bundle changes are part of the PR to avoid letting the bundle in a broken state. I will also submit them to the doctrine/DoctrineBundle repo
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/12/16 02:33:05 -0800
    
    Tests do not pass for me (even after upgrading the Doctrine deps to their latest versions):
    
        There was 1 error:
    
        1) Symfony\Bundle\DoctrineBundle\Tests\ContainerTest::testContainer
        Argument 1 passed to Doctrine\DBAL\Logging\LoggerChain::addLogger() must implement interface Doctrine\DBAL\Logging\SQLLogger, instance of Doctrine\Dbal\Logging\DebugStack given
    
        vendor/doctrine-dbal/lib/Doctrine/DBAL/Logging/LoggerChain.php:39
        src/Symfony/Component/DependencyInjection/ContainerBuilder.php:777
        src/Symfony/Component/DependencyInjection/ContainerBuilder.php:349
        src/Symfony/Bundle/DoctrineBundle/Tests/ContainerTest.php:22
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/12/16 04:24:46 -0800
    
    this is weird. DebugStack implements the interface, and the test passes for me
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/12/16 05:30:11 -0800
    
    actually, the test pass when I run the `ContainerTest.php` file alone, but fail when I'm running the whole test suite.
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/12/16 05:39:15 -0800
    
    I'm not able to run the whole testsuite. With intl enabled, it fails before the first test somewhere in the Locale component tests (Intl seems to be broken on 5.3.8 on windows as using the constructor of the intl classes gives me ``null`` in the variable). And after disabling intl, I got an error about allowed memory size exhausted during the EntityType tests
    
    ---------------------------------------------------------------------------
    
    by stloyd at 2011/12/16 05:42:09 -0800
    
    @stof And here goes Travis with help! ;-)
    
    Just log in there, enable hook for your symfony repo, force an push, and watch result at: http://travis-ci.org/#!/stof/symfony
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/12/16 05:47:57 -0800
    
    Note: when running only the testsuite for bundles, I also get such an error after about 450 of the 500 tests. It seems like the garbage collector does not clean the memory between tests...
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/12/16 05:52:08 -0800
    
    anyway, the error seems really weird as the class implements the interface. I don't see how it could be passed without implementing it
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/12/16 06:10:43 -0800
    
    @stloyd Travis allows me to see that this issue is not specific to @fabpot's computer. But it does not allow me to debug the test as I only get the result of the test, which does not make any sense
  6. @fabpot

    merged branch kriswallsmith/process/builder (PR #2902)

    fabpot authored
    Commits
    -------
    
    d7712a3 [Process] added ProcessBuilder
    
    Discussion
    ----------
    
    [Process] added ProcessBuilder
    
    This class was copied from Assetic.
    
    ```
    Bug fix: no
    Feature addition: yes
    BC break: no
    Symfony2 test pass: oui
    ```
Commits on Dec 16, 2011
  1. @kriswallsmith

    [Process] added ProcessBuilder

    kriswallsmith authored
    This class was copied from Assetic.
  2. @fabpot

    merged branch drak/frameworkbundle_moretests (PR #2904)

    fabpot authored
    Commits
    -------
    
    9b8cdab [FrameworkBundle] Prove client insulation and non-insulation works in session tests.
    ce66548 [FrameworkBundle] Add tests to prove functional testing works with simultaneous clients.
    ff0412a [FrameworkBundle] Small changes to test setup.
    
    Discussion
    ----------
    
    [FrameworkBundle] Added functional tests to prove multiple clients and client insulation.
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: -
    References: #2898
    Todo: -
    
    @fabpot: I don't know what happened with the previous PR #2989 - seemed like some weird corruption as the tests passed locally and on travis except until after I fetched from the repo.  I suspect something was corrupted.  I asked @Seldaek to confirm the tests pass on his local setup before I submitted this PR.  I only got rid of the errors locally after recloning the repo!
    
    http://travis-ci.org/#!/drak/symfony/builds/413515
    
    [![Build Status](https://secure.travis-ci.org/drak/symfony.png)](http://travis-ci.org/drak/symfony?branch=frameworkbundle_moretests)
  3. [FrameworkBundle] Add tests to prove functional testing works with si…

    Drak authored
    …multaneous clients.
  4. @stof

    [DoctrineBridge][DoctrineBundle] Refactored the DBAL logging

    stof authored
    This allows enabling the logging and the profiling separately for instance
    when doing batch processing leading to memory issue due to the profiling.
  5. @fabpot

    merged branch aboks/doctrine-profiler-view (PR #2897)

    fabpot authored
    Commits
    -------
    
    662fdc3 [DoctrineBundle] Fixed incorrectly shown params
    
    Discussion
    ----------
    
    Doctrine profiler view
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: -
    Todo: -
    
    After the changes in #2733, the parameters to Doctrine queries were
    always shown as 'Array' in the profiler. This commit puts back the
    yaml_encode that is still needed after all.
  6. @fabpot
  7. @aboks

    [DoctrineBundle] Fixed incorrectly shown params

    aboks authored
    After the changes in #2733, the parameters to Doctrine queries were
    always shown as 'Array' in the profiler. This commit puts back the
    yaml_encode that is still needed after all.
Commits on Dec 15, 2011
  1. @fabpot
  2. @fabpot

    [SwiftmailerBundle] fixed the send email command when the queue does …

    fabpot authored
    …not extends Swift_ConfigurableSpool
  3. @fabpot

    Merge branch '2.0'

    fabpot authored
    * 2.0:
      [FrameworkBundle] Added functional tests.
      [Form] Added missing use statements (closes #2880)
      [Console] Improve input definition output for Boolean defaults
      [SecurityBundle] Changed environment to something unique.
      2879: missing space between catch and the brace
      #2688: Entities are generated in wrong folder (doctrine:generate:entities Namespace)
      [TwigBundle] Fix the exception message escaping
  4. @fabpot

    [HttpKernel] added request and response as arguments to the Terminabl…

    fabpot authored
    …eInterface::terminate() method
  5. @fabpot

    updated CHANGELOG for 2.1

    fabpot authored
  6. @fabpot

    merged branch Seldaek/post_response (PR #2791)

    fabpot authored
    Commits
    -------
    
    7c2f11f Merge pull request #1 from pminnieur/post_response
    9f4391f [HttpKernel] fixed DocBlocks
    2a61714 [HttpKernel] added PostResponseEvent dispatching to HttpKernel
    915f440 [HttpKernel] removed BC breaks, introduced new TerminableInterface
    7efe4bc [HttpKernel] Add Kernel::terminate() and HttpKernel::terminate() for post-response logic
    
    Discussion
    ----------
    
    [HttpKernel] Add Kernel::terminate() and HttpKernel::terminate() for post-response logic
    
    This came out of a discussion on IRC about doing stuff post-response, and the fact that right now there is no best practice, and it basically requires adding code after the `->send()` call.
    
    It's an attempt at fixing it in an official way. Of course terminate() would need to be called explicitly, and added to the front controllers, but then it offers a standard way for everyone to listen on that event and do things without slowing down the user response.
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/12/06 02:41:26 -0800
    
    We discussed it on IRC and I suggested a way to avoid the BC break of the interface: adding a new interface (``TerminableInterface`` or whatever better name you find) containing this method.
    HttpKernel, Kernel and HttpCache can then implement it without breaking the existing apps using the component (Kernel and HttpCache would need an instanceof check to see if the inner kernel implements the method)
    
    For Symfony2 users it will mean they have to change their front controller to benefit from the new event of course, but this is easy to do.
    
    Btw, Silex can then be able to use it without *any* change for the end users as it can be done inside ``Application::run()``
    
    ---------------------------------------------------------------------------
    
    by pminnieur at 2011/12/06 11:47:03 -0800
    
    @Seldaek: I opened a pull request so that the discussion on IRC is fulfilled and no BC breaks exist: https://github.com/Seldaek/symfony/pull/1/files
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/12/07 07:59:49 -0800
    
    Any real-world use case for this?
    
    ---------------------------------------------------------------------------
    
    by Seldaek at 2011/12/07 08:10:31 -0800
    
    Doing slow stuff after the user got his response back without having to implement a message queue. I believe @pminnieur wanted to use it to send logs to loggly?
    
    ---------------------------------------------------------------------------
    
    by pminnieur at 2011/12/07 09:08:41 -0800
    
    Its a good practice to defer code execution without the introduction of a new software layer (like gearman, amqp, whatever tools people use to defer code execution) which may be way too much just for the goal of having fast responses, whatever my code does.
    
    My real world use case which made me miss this feature the first time:
    
     > I have a calendar with a scheduled Event. For a given period of time, several Event entities will be created, coupled to the scheduled event (the schedule Event just keeps track of `startDate`, `endDate` and the `dateInterval`). Let's say we want this scheduled Event to be on every Monday-Friday, on a weekly basis, for the next 10 years.
    
    This means I have to create `10*52*5` Event entities before I could even think about sending a simple redirect response. If I could defer code execution, I'd only save the scheduled Event, send the redirect response and after that, I create the `10*52*5` entities.
    
    The other use case was loggly, yes. Sending logging data over the wire before the response is send doesn't make sense in my eyes, so it could be deferred after the response is send (this especially sucks if loggly fails and i get a 500 --the frontend/public user is not interested in a working logging facility, he wants his responses).
    
    ---------------------------------------------------------------------------
    
    by mvrhov at 2011/12/07 10:07:03 -0800
    
    This would help significantly, but the real problem, that your process is busy and unavailable for the next request, is still there.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/12/07 10:15:18 -0800
    
    I think this is the wrong solution for a real problem.
    
    Saying "Its a good practice to defer code execution without the introduction of a new software layer" is just wrong.
    
    It is definitely a good practice to defer code execution, but you should use the right tool for the job.
    
    I'm -1.
    
    ---------------------------------------------------------------------------
    
    by pminnieur at 2011/12/07 10:25:44 -0800
    
    It should just give a possibility to put unimportant but heavy lifting code behind the send request with ease. With little effort people could benefit from the usage of `fastcgi_finish_request` without introducing new software, using `register_shutdown_function` or using `__destruct `(which works for simple things, but may act weird with dependencies).
    
    It should not simulate node.js ;-) I agree that the real problem is not solved, but small problems could be solved easily. I personally don't want to setup RabbitMQ or whatever, maintain my crontab or any other software that may allow me to defer code execution.
    
    ---------------------------------------------------------------------------
    
    by Seldaek at 2011/12/08 01:08:32 -0800
    
    @fabpot: one could say that on shared hostings it is still useful because they generally don't give you gearman or \*MQs. Anyway I think it'd be nice to really complete the HttpKernel event cycle.
    
    ---------------------------------------------------------------------------
    
    by pminnieur at 2011/12/08 01:48:57 -0800
    
    not only on shared hostings, sometimes teams/projects just don't have the resources or knowledge or time to setup such an infrastructure.
    
    ---------------------------------------------------------------------------
    
    by videlalvaro at 2011/12/08 01:53:06 -0800
    
    I can say we used `fastcgi_finish_request` quite a lot at poppen with symfony 1.x. It certainly helped us to send data to Graphite, save XHProf runs, send data to RabbitMQ, and so on.
    
    For example we used to connect to RabbitMQ and send the messages _after_ calling `fastcgi_finish_request` so the user never had to wait for stuff like that.
    
    Also keep in mind that if you are using Gearman or RabbitMQ or whatever tool you use to defer code execution… you are not deferring the network connection handling, sending data over the wire and what not. I know this is obvious but is often overlooked.
    
    So it would be nice to have an standard way of doing this.
    
    ---------------------------------------------------------------------------
    
    by henrikbjorn at 2011/12/13 01:42:23 -0800
    
    This could have been useful recently while implementing a "Poor mans cronjob" system. The solution was to do a custom Response object and do the stuff after send have been called with a Connection: Close header and ignore_user_abort(); (Yes very ugly)
  7. @fabpot

    merged branch drak/securitybundle_test (PR #2888)

    fabpot authored
    Commits
    -------
    
    62f3dc4 [SecurityBundle] Changed environment to something unique.
    
    Discussion
    ----------
    
    [SecurityBundle] Fix name clash with functional tests
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: -
    Todo: -
    
    Functional tests need a unique environment or it will produce class redeclare errors when multiple bundles are functional tested at the same time.
  8. @fabpot

    merged branch drak/frameworkbundle_sessiontest (PR #2887)

    fabpot authored
    Commits
    -------
    
    ba7d810 [FrameworkBundle] Added functional tests.
    
    Discussion
    ----------
    
    [FrameworkBundle] Added functional tests
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: -
    Todo: -
    
    Tests session attributes and flash messages APIs in functional practice. These tests increase coverage of this important area and make any future work on sessions much more reliable.
  9. [FrameworkBundle] Added functional tests.

    Drak authored
    Added functional tests to prove session attributes and flashes in practice.
  10. @fabpot

    merged branch stloyd/missing_use_statement (PR #2886)

    fabpot authored
    Commits
    -------
    
    8069ea6 [Form] Added missing use statements (closes #2880)
    
    Discussion
    ----------
    
    [Form] Missing use statements
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: #2880
  11. @stloyd
  12. @fabpot

    merged branch jmikola/2.0-inputDefinition (PR #2885)

    fabpot authored
    Commits
    -------
    
    d5a1343 [Console] Improve input definition output for Boolean defaults
    
    Discussion
    ----------
    
    [Console] Improve input definition output for Boolean defaults
    
    This addresses an annoyance I had with command help printing `(default: )` for arguments and options that default to `false`.
    
    ```
    Bug fix: no
    Feature addition: yes
    Backwards compatibility break: no (documentation text/XML output is slightly changed)
    Symfony2 tests pass: yes
    ```
  13. @jmikola

    [Console] Improve input definition output for Boolean defaults

    jmikola authored
    Previously, Boolean defaults were printed as strings, which lead to true and false being printed as "1" and "", respectively. With this change, they are now printed as "true" and "false".
  14. [SecurityBundle] Changed environment to something unique.

    Drak authored
    If you run functional tests from different bundles you it will cause a redeclare error
    because the DIC appKernel name is not unique.
Commits on Dec 14, 2011
  1. @fabpot

    merged branch lsmith77/serializer_interface (PR #2530)

    fabpot authored
    Commits
    -------
    
    0776b50 removed supports(De)Serializiation()
    72b9083 SerializerAwareNormalizer now only implements SerializerAwareInterface
    97389fa use Serializer specific RuntimeException
    cb495fd added additional unit tests for deserialization
    967531f fixed various typos from the refactoring
    067242d updated serializer tests to use the new interfaces
    d811e29 CS fix
    351eaa8 require a (de)normalizer inside the (de)normalizable interfaces instead of a serializer
    c3d6123 re-added supports(de)normalization()
    078f7f3 more typo fixes
    c3a711d abstract class children should also implement dernormalization
    2a6741c typo fix
    d021dc8 refactored encoder handling to use the supports*() methods to determine which encoder handles what format
    f8e2787 refactored Normalizer interfaces
    58bd0f5 refactored the EncoderInterface
    b0daf35 split off an EncoderInterface and NormalizerInterface from SerializerInterface
    
    Discussion
    ----------
    
    [Serializer] split off an EncoderInterface and NormalizerInterface from SerializerInte
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: yes (but not inside a stable API)
    Symfony2 tests pass: ![Build Status](https://secure.travis-ci.org/lsmith77/symfony.png?branch=serializer_interface)
    Fixes the following tickets: #2153
    
    The purpose is to make it easier for other implementations that only implement parts of the interface due to different underlying approaches like the JMSSerializerBundle.
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2011/11/01 03:36:17 -0700
    
    Actually, you can keep the current interface and I will just provide an adapter, sth like the following:
    
    ```php
    <?php
    
    class SymfonyAdapter implements SymfonyInterface
    {
        public function __construct(BundleInterface $serializer) { /* ... */ }
        // symfony serializer methods mapped to bundle methods
    }
    ```
    I like to provide an adapter instead of implementing the interface directly since the bundle can be used standalone right now, and I don't want to add a dependency on the component just for the sake of the interface.
    
    However, I do not completely see the purpose of the component. When would someone be recommended to use it? Everything the component does, the bundles does at the same level with the same complexity or simplicity (however you want to view that).
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/11/01 03:40:55 -0700
    
    standalone in what way? you mean even out of the context of Symfony? In that context imho you should ship that code outside of a Bundle.
    
    Regardless, how will that adaptor work? How would you implement methods like ``getEncoder()``? Afaik you can't and this is what this PR is about, splitting the interface to enable people to more finely specify what they provide.
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2011/11/01 04:03:56 -0700
    
    I would just throw exceptions when something is not supported.
    
    The more important question though is what is the goal of the component in the long-term, i.e. what problems is it supposed to solve, or in which cases should it be used?
    
    Because right now it seems to me - correct me if I'm wrong - that the only purpose is that people don't have to install an extra library. However, that might even be frustrating for users because they need to migrate their code to the bundle as soon as they need to customize the serialization process which you need in 99% of the cases. For deserialization, the situation in the component is even worse. So, if my assessment is correct here (i.e. component to get started fast, if you need more migrate to the bundle), I think it would be better and less painful to have them start with the bundle right away.
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/11/01 04:15:10 -0700
    
    Well then imho it would be better to split the interface.
    
    I think the serializer component is sufficient for many situations and imho its easier to grok. Furthermore the normalizer/encoder concept it can be used in situations where JMSSerializerBundle cannot be used.
    
    And splitting up the interfaces has exactly the goal of reducing the "frustrations" caused by out growing the the component.
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2011/11/01 04:29:39 -0700
    
    I don't agree, but it's a subjective thing anyway.
    
    So, whatever interface you come up with (preferably as few methods as possible), I will provide an adapter for it.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/11/07 08:45:25 -0800
    
    What's the status of this PR?
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/11/07 10:28:14 -0800
    
    from my POV its good to go. but would like a nod from someone else in terms of the naming of the new interfaces
    
    On 07.11.2011, at 17:45, Fabien Potencier <reply@reply.github.com> wrote:
    
    > What's the status of this PR?
    >
    > ---
    > Reply to this email directly or view it on GitHub:
    > symfony#2530 (comment)
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/11/08 11:37:40 -0800
    
    @lsmith77 what about doing the same for the ``NormalizerInterface`` instead of adding a new interface with a confusing name ? The Serializer class could implement ``Normalizer\NormalizerInterface`` by adding the 2 needed methods instead of duplicating part of the interface.
    
    The next step is to refactor the Serializer class so that it choose the encoder and the decoder based on the ``support*`` methods. But this could probably be done in a separate PR.
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/11/08 11:51:27 -0800
    
    yeah .. i wanted to do that once we are in agreement on the encoder stuff. question then is if we should again split off Denormalization. i guess yes.
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/11/08 12:06:34 -0800
    
    ok done ..
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/11/08 12:59:51 -0800
    
    i guess the next big task is to add more tests .. had to fix way too few unit tests with all this shuffling around .. will also help validating the concept. i should also test this out in a production application.
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/11/14 13:27:48 -0800
    
    @ericclemmons can you also have a look at this PR and potentially help me adding tests?
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/12/07 07:32:06 -0800
    
    @lsmith77: Is it ready to be merged? Should I wait for more unit tests?
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/07 07:34:56 -0800
    
    If you merge it I am afraid I might get lazy and not write tests. This is why I changed the topic to WIP. I promise to finish this on the weekend.
    
    Note however I was planning to write the tests for 2.0 and send them via a separate PR.
    Once that PR is merged into 2.0 and master. I would then refactor them to work for this PR.
    This way both 2.0 and master will have tests.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/12/07 07:42:15 -0800
    
    @lsmith77: sounds good. Thanks.
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/11 12:02:12 -0800
    
    @fabpot ok i am done from my end.
    @schmittjoh would be great if you could look over the final interfaces one time and give your blessing that you will indeed be able to provide implementations for these interfaces inside JMSSerializerBundle (even if just via an adapter)
    
    ---------------------------------------------------------------------------
    
    by stof at 2011/12/12 12:43:49 -0800
    
    @schmittjoh can you take a look as requested by @lsmith77 ?
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2011/12/13 03:33:23 -0800
    
    Are the supports methods necessary? This is what I'm using in the bundle:
    https://github.com/schmittjoh/JMSSerializerBundle/blob/master/Serializer/SerializerInterface.php
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/13 04:08:49 -0800
    
    @schmittjoh without them determining if something is supported will always require an exception, which is pretty expensive. especially if one iterates over a data structure this can cause a lot of overhead.
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2011/12/13 04:24:18 -0800
    
    my question was more if you have a real-world use case where this is useful?
    
    On Tue, Dec 13, 2011 at 1:08 PM, Lukas Kahwe Smith <
    reply@reply.github.com
    > wrote:
    
    > @schmittjoh without them determining if something is supported will always
    > require an exception, which is pretty expensive. especially if one iterates
    > over a data structure this can cause a lot of overhead.
    >
    > ---
    > Reply to this email directly or view it on GitHub:
    > symfony#2530 (comment)
    >
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/13 04:28:08 -0800
    
    yes .. this serializer .. since it traverses the tree and decides what is the current normalizer one by one (aka not via visitors as in your implementation). without the supports*() methods it would need to have the normalizer throw exceptions, but this is not exceptional, its the normal code flow to have to iterate to find the correct normalizer.
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2011/12/13 04:30:36 -0800
    
    can we split it off into a second interface?
    
    On Tue, Dec 13, 2011 at 1:28 PM, Lukas Kahwe Smith <
    reply@reply.github.com
    > wrote:
    
    > yes .. this serializer .. since it traverses the tree and decides what is
    > the current normalizer one by one (aka not via visitors as in your
    > implementation). without the supports*() methods it would need to have the
    > normalizer throw exceptions, but this is not exceptional, its the normal
    > code flow to have to iterate to find the correct normalizer.
    >
    > ---
    > Reply to this email directly or view it on GitHub:
    > symfony#2530 (comment)
    >
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/13 04:33:27 -0800
    
    hmm .. i guess we could .. these methods in a way are implementation specific and are mainly public because its different objects interacting with each other, though for users of the lib they can also be convenient at times.
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/14 09:13:53 -0800
    
    ok i reviewed things again and just removed those two methods, since the possibility for these methods to be feasible is too tied to the implementation and for this particular implementation supportsEncoding() and supportsDecoding() are still available.
    
    so all ready to be merged ..
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/14 09:15:44 -0800
    
    hmm i realized one thing just now:
    lsmith77@cb495fd
    
    that commit should also be included in 2.0 .. i am not sure what the most elegant way is to make that happen ..
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2011/12/14 10:10:16 -0800
    
    @lsmith77: commit cb495fd cannot be cherry picked in 2.0 as is as the tests do not pass:  "Fatal error: Call to undefined method Symfony\Component\Serializer\Serializer::supportsDenormalization() in tests/Symfony/Tests/Component/Serializer/SerializerTest.php on line 150"
    
    ---------------------------------------------------------------------------
    
    by lsmith77 at 2011/12/14 10:11:55 -0800
    
    ah of course .. i just removed that method :) .. then never mind .. all is well.
  2. @fabpot

    merged branch alexandresalome/fix-exception-new-line (PR #2870)

    fabpot authored
    Commits
    -------
    
    f3e92c4 [TwigBundle] Fix the exception message escaping
    
    Discussion
    ----------
    
    [2.0][TwigBundle] Fix exception new line
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: -
  3. @fabpot

    merged branch arnogeurts/PR-2688 (PR #2879)

    fabpot authored
    Commits
    -------
    
    7ac43fc 2879: missing space between catch and the brace
    0900ecc #2688: Entities are generated in wrong folder (doctrine:generate:entities Namespace)
    
    Discussion
    ----------
    
    [Console] [Doctrine] Fixed: Entities are generated in wrong folder (doctrine:generate:entities Namespace)
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: no
    Fixes the following tickets: 2688
    Todo: -
    
    See PR 2746 for the description of the bug.
    
    Bug-description:
    Running the command "$php app/console doctrine:generate:entities [bundle name]" from the commandline throws an exception when the entities do not exist yet. Because metadata of the entity class could not be retrieved.
    
    Bugfix:-description:
    Fall back to bundle metadata when no entity metadata could not be retrieved.
  4. @fabpot

    merged 2.0

    fabpot authored
  5. @lsmith77
  6. 2879: missing space between catch and the brace

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