[TwigBridge] Added a TwigEngine in the bridge

This TwigEngine implements the interface available in the component.
the TwigBridge in TwigBundle now extends this class and provides only
the additional methods for the FrameworkBundle interface.
moved event dispatcher classes to the EventDispatcher component
merged branch symfony/event_dispatcher_classes_move (PR #3760)

Commits
-------

93848be moved event dispatcher classes to the EventDispatcher component

Discussion
----------

moved event dispatcher classes to the EventDispatcher component

I have moved the two specialized event dispatcher classes from the FrameworkBundle bundle to the EventDispatcher component.

It makes them reusable outside the Symfony full-stack framework as they can be quite useful (people like @drak has a use for them for instance).

It makes the event dispatcher component *optionally* rely on DependencyInjection and HttpKernel for these classes, like what we have in other components.

What do you think?

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

by stof at 2012-04-02T16:02:01Z

you forgot to update the ``suggests`` section of the composer.json file. Otherwise, it is fine

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

by drak at 2012-04-02T16:06:34Z

w00t, thanks @fabpot!

I'm biased of course, but the optional dependency to `DependencyInjection` is a much more logical dependency that the previous one, to `FrameworkBundle`. It immediately shows of the DIC also.

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

by schmittjoh at 2012-04-02T16:06:39Z

+1, the "no dependencies" should really be changed to "minimal dependencies"

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

by henrikbjorn at 2012-04-02T16:09:48Z

@schmittjoh should properly be "minimal optional dependencies" otherwise people will be scared i think :) And reading "minimal dependencies" reminds me when trying to use a zf1 component standalone.

+1

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

by drak at 2012-04-02T16:12:57Z

@schmittjoh Honestly speaking, some of the Sf2 components do already have a few dependencies with each other, but where there are, they all minimal and rather logical anyway.  It's not like some libraries I could mention where one lib required about 10 deps which each rely on a bunch of other things - in the end, you need everything just for one feature :-P

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

by stof at 2012-04-02T16:14:28Z

@drak there was not optional dependency to FrameworkBundle previously as no code of the component was using FrameworkBundle (the dependency was the other way)

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

by drak at 2012-04-02T16:18:31Z

@stof, yeah but I was talking about other components like Security, DependencyInjection, HttpKernel for example which has a mix of optional and required deps.  It's not true to say all Sf2 components are 100% standalone in all cases.
Updated the changelog
[ClassLoader] Added a DebugClassLoader using composition
merged branch stof/twig_engine_move (PR #3761)

Commits
-------

dbab7e1 [TwigBridge] Added a TwigEngine in the bridge

Discussion
----------

[TwigBridge] Added a TwigEngine in the bridge

This TwigEngine implements the interface available in the component.
the TwigBridge in TwigBundle now extends this class and provides only
the additional methods for the FrameworkBundle interface.

This will allow people to support the PhpEngine and Twig in their code more easily when using the component as they don't need to reimplement the class.
I originally thought about when I helped @dragoonis to integrate the Templating component in the PPI framework 2.0 as he talked about adding the support for Twig later too.
Added an exception when passing an invalid object to ApcClassLoader
merged branch stof/autoloader_refactoring (PR #3756)

Commits
-------

f1f1494 Added an exception when passing an invalid object to ApcClassLoader
f5cb167 [ClassLoader] Added a DebugClassLoader using composition
0e54a22 Updated the changelog
eae772e [ClassLoader] Added an ApcClassLoader
4d1333f Changed the test autoloading to use the new autoloader
09850bd [ClassLoader] Added a simplified PSR-0 ClassLoader

Discussion
----------

Autoloader refactoring

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/stof/symfony.png?branch=autoloader_refactoring)](http://travis-ci.org/stof/symfony)

As discussed in #3623, I added a new ClassLoader instead of modifying the UniversalClassLoader, to be able to use the method names without BC concerns. The new class works the same than the composer autoloader regarding the handling of fallbacks, to be able to reuse namespace maps generated by composer.

```php
<?php

// autoload.php
require_once __DIR__.'/vendor/symfony/class-loader/Symfony/Component/ClassLoader/ClassLoader.php';

$loader = new Symfony\Component\ClassLoader\ClassLoader();

$map = require __DIR__.'/vendor/.composer/autoload_namespaces.php';
$loader->addPrefixes($map);

$loader->register();
```

Differences with the composer class loader:

- Composer's ``add`` method is named ``addPrefix`` in the Symfony ClassLoader
- the methods related to the class map are removed as Symfony has a separate laoder for class maps
- the ``addPrefixes`` method is added, accepting a namespace map.

I also added a new ApcClassLoader which uses composition instead of inheriting from a class loader, which makes it far more easier to reuse (we could wrap a Composer autoloader with it for instance).

```php
<?php

$composerLoader = require __DIR__.'/vendor/.composer/autoload.php';

// no need to require the file manually as Composer already registered its autoloader
$cachedLoader = new Symfony\Component\ClassLoader\ApcClassLoader('autoload.my_app', $composerLoader);

$cachedLoader->register();
// unregister the Composer autoloader as we wrapped it in the ApcClassLoader
$composerLoader->unregister();
```

TODO:

- refactor the Debug class loader to use composition too to be able to support different class loaders

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

by fabpot at 2012-04-02T16:31:28Z

Can you update the CHANGELOG and the UPGRADE file accordingly?

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

by stof at 2012-04-02T16:47:43Z

I added a note in the CHANGELOG. There is nothing to add in the UPGRADE file as the change is fully BC (I did not change the UniversalClassLoader at all so it can still be used).

I'm working on the Debug loader right now so please wait a bit before merging

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

by stof at 2012-04-02T17:12:11Z

Here is a new DebugClassLoader using composition too. this way, it is able to support the UniversalClassLoader, the ApcUniversalClassLoader (without dropping the use of APC as done previously), the new ClassLoader, the new ApcClassLoader and even the composer autoloader.
I'm not sure about the use of ``method_exists`` as it could break if an autoloader implements a protected ``findFile`` method (crappy PHP :cry:) but hardcoding the supported classes would be a pain and requiring an interface would make the autoloaders more difficult to use (as the interface would need to be required first) and would drop the support of the composer autoloader.
performance improvement in PhpMatcherDumper
merged branch Tobion/PhpMatcherDumper-Improvement (PR #3763)

Commits
-------

56c1e31 performance improvement in PhpMatcherDumper

Discussion
----------

performance improvement in PhpMatcherDumper

Tests pass: yes

The code generation uses a string internally instead of an array. The array wasn't used for random access anyway.
I also removed 4 unneeded iterations this way (when imploding, when merging and twice when applying the extra indention). A `preg_replace` could also be saved under certain circumstances by moving it.
And there was a small code errror in line 139.
merged branch drak/sessionmeta (PR #3718)

Commits
-------

8a0e6d2 [HttpFoundation] Update changelog.
4fc04fa [HttpFoundation] Renamed MetaBag to MetadataBag
2f03b31 [HttpFoundation] Added the ability to change the session cookie lifetime on migrate().
39141e8 [HttpFoundation] Add ability to force the lifetime (allows update of session cookie expiry-time)
ec3f88f [HttpFoundation] Add methods to interface
402254c [HttpFoundation] Changed meta-data responsibility to SessionStorageInterface
d9fd14f [HttpFoundation] Refactored for moved tests location.
29bd787 [HttpFoundation] Added some basic meta-data to Session

Discussion
----------

[2.1][HttpFoundation] Added some basic meta-data to Session

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

Session data is stored as an encoded string against a single id.  If we want to store meta-data about the session, that data has to be stored as part of the session data to ensure the meta-data can persist using any session save handler.

This patch makes it much easier to determine the logic of session expiration.  In general a session expiry can be dealt with by the gc handlers, however, in some applications more specific expiry rules might be required.

Session expiry may also be more complex than a simple, session was idle for x seconds.  For example, in Zikula there are three security settings, Low, Medium and High.  The rules for session expiry are more complex as under the Medium setting, a session will expire after x minutes idle time, unless the rememberme option was ticked on login.  If so, the session will not idle.  This gives the user some control over their experience.  Under the high security setting, then there is no option, sessions will expire after the idle time is reached and login the UI has the rememberme checkbox removed.

The other advantage is that under this methodology, there can be a UI experience on expiry, like "Sorry, your session expired due to being idle for 10 minutes".

Keeping in the spirit of Symfony2 Components, I am seeking to make session handling flexible enough to accommodate these general requirements without specifically covering expiration rules. It would mean that it would be up to the implementing application to specifcally check and expire session after starting it.

Expiration might look something like this:

    $session->start();
    if (time() - $session->getMetadataBag()->getLastUpdate() > $maxIdleTime) {
        $session->invalidate();
        throw new SessionExpired();
    }

This commit also brings the ability to change the `cookie_lifetime` when migrating a session. This means one could move from a default of browser only session cookie to long-lived cookie when changing from a anonymous to a logged in user for example.

    $session->migrate($destroy, $lifetime);

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

by drak at 2012-03-30T18:18:43Z

@fabpot I have removed [WIP] status.

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

by drak at 2012-03-31T13:34:57Z

NB: This PR has been rebased and the tests relocated as per recent master changes.

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

by drak at 2012-04-03T02:16:43Z

@fabpot - ping
merged branch jfsimon/master (PR #3613)

Commits
-------

2a90871 [Console] Removed previously introduced BC break.
90a2a6e [Console] Undecorated formatter must update style stack too.
bd7e01a [Console] Fixed output formatter test broken by new implementation.
a1add4b [Console] Updated output formatter to use style stack.
4f298dd [Console] Added formatter style stack.
93ffe54 [Console] Added getters to output formatter style (and its interface).
48e6b49 [Console] Updated formatter test to match styles bug fix.
ad334b6 [Console] Fixed empty style appliance.
31d5fe5 [Console] Fixed output formatter docblock.

Discussion
----------

[Console] Fixes formatter nested style appliance.

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes

When outputing styled text in the console, you sometimes face to a confusing behavior: style tags cannot be nested. If tou try something like `<fg=blue>Hello <fg=red>world</fg=red>!</fg=blue>`, the trailing `!` will not be styled.

This PR introduce a new FormatterOutputStyleStack to keep open/closed styles informations up-to-date. It slightly changes OutputFormatter implementation which no longer uses `OutputFormatterStyle::apply()` method, but the new `OutputFormatterStyle::getTerminalSequence()`.

**Question:** I don't une `OutputFormatterStyleInterface` but `OutputFormatterStyle` to type `OutputFormatterStyleStack` methods arguments (to avoid BC break on the interface). Do you think it's right?

**Notice:** I also needed to fix some tests broken by new implementation.

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

by stof at 2012-03-16T10:27:56Z

Adding new methods in an interface is a BC break for people implementing it

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

by jfsimon at 2012-03-16T10:33:21Z

@stof indeed... this is a problem, should I remove them? If I do so, I should use `OutputFormatterStyle` instead of the interface to type arguments in `OutputFormatterStyleStack` right?
slovenian translations updated to latest list
merged branch maastermedia/translations (PR #3769)

Commits
-------

2519544 slovenian translations updated to latest list

Discussion
----------

Slovenian translations updated to latest list

Thank you!