merged branch eriksencosta/locale-fixes-2.0 (PR #3955)

Commits
-------

fab1b5a [Locale] changed inequality operator to strict checking and updated some assertions
09d30d3 [Locale] refactored some code
e4cbbf3 [Locale] fixed StubNumberFormatter::format() to behave like the NumberFormatter::parse() regarding to error flagging
f16ff89 [Locale] fixed StubNumberFormatter::parse() to behave like the NumberFormatter::parse() regarding to error flagging
0a60664 [Locale] updated StubIntlDateFormatter::format() exception message when timestamp argument is an array for PHP >= 5.3.4
e4769d9 [Locale] reordered test methods
312a5a4 [Locale] fixed StubIntlDateFormatter::format() to set the right error for PHP >= 5.3.4 and to behave like the intl when formatting successfully

Discussion
----------

[2.0][Locale] some fixes

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

Fixed some inconsistencies between the stub and the intl implementation:

 - `StubIntlDateFormatter::format()` to set the right error for PHP >= 5.3.4 and to behave like the intl when formatting successfully
 - updated `StubIntlDateFormatter::format()` exception message when timestamp argument is an array for PHP >= 5.3.4
 - `StubNumberFormatter::parse()` to behave like the NumberFormatter::parse() regarding to error flagging
 - `StubNumberFormatter::format()` to behave like the NumberFormatter::parse() regarding to error flagging
merged branch stealth35/locale_intl_error_name (PR #3959)

Commits
-------

5799d25 Add BOGUS UErrorCode test
6f9c05d [Locale] Complete Stub with intl_error_name

Discussion
----------

[Locale] Complete StubIntl with the missing intl_error_name

    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: -
    Todo: -
merged 2.0
fixed CS
fixed previous merge
fixed typo
merged branch canni/composer (PR #3291)

Commits
-------

aa055df [Composer] Stwitch to composer vendors management

Discussion
----------

[Composer] Stwitch to composer vendors management

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

[![Build Status](https://secure.travis-ci.org/canni/symfony.png?branch=composer)](http://travis-ci.org/canni/symfony)

This speeds up Travis CI builds to `~2 min` also makes vendor management
a lot easier.

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

by fabpot at 2012-02-09T06:24:24Z

I'm -1 on this change. The `vendors.php` script is *only* for people working on the core so that we can run the unit tests. So, we need the flexibility to test on many different versions of the code and having the repository here is kind of mandatory.

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

by Seldaek at 2012-02-09T08:15:28Z

You can `composer install --dev` to get proper clones. I'm not really pro or against, just saying it's an option.

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

by canni at 2012-02-09T08:28:54Z

@fabpot I understand yours point, but from my view transferring the whole git structure of *vendors* is little pointless IMO (especially in Travis env)
but I think I can make this change optional, so Travis and anyone that prefer to, can use `composer` an with old functionality available.

(There will be almost no duplication, as anyway we're updating `composer.json`)

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

by canni at 2012-02-09T09:20:17Z

@fabpot I've enabled both behaviors, everything will work regardless of using `composer` or `vendors.php` this lets the developer decide what to use

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

by drak at 2012-02-16T12:05:28Z

Since there is a `--dev` option in Composer then I think this is a good idea.  You could also add composer.phar to the repo bin  directory.

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

by henrikbjorn at 2012-02-16T12:06:55Z

`--dev` have been renamed to `--prefer-source`

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

by canni at 2012-02-16T12:22:01Z

@fabpot any chance to consider this merge? If not, this PR can be closed.

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

by henrikbjorn at 2012-02-16T12:25:51Z

@canni This is the goal eventually. But i think we need composer to be a bit more stable in its solver.

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

by francoispluchino at 2012-02-16T12:39:24Z

:+1:

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

by jmikola at 2012-04-06T18:19:27Z

@fabpot: Is this PR still off the table, or are you reconsidering it with the `--prefer-source` option? I was just running symfony unit tests, and attempted to install deps with composer as I thought this PR or another like it had recently been merged to core. It wasn't :)

Admittedly, it's a downside that vendor libs, even if git repositories, will be nestled within the `.composer/` directory.

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

by drak at 2012-04-07T00:20:33Z

@canni This PR needs to be rebased and reviewed because of the changed tests directory (there is no longer a central `tests/` folder).

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

by canni at 2012-04-07T06:34:28Z

Hey,

will do after a weekend.

canni

Użytkownik Drak <reply@reply.github.com> napisał:

>@canni This PR needs to be rebased and reviewed because of the changed tests directory (there is no longer a central `tests/` folder).
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/symfony/symfony/pull/3291#issuecomment-5004750

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

by canni at 2012-04-08T19:02:03Z

@drak done.
tweaked previous merge
Revert "merged branch jakzal/2.0-StaticMethodLoaderFix (PR #3937)"

This reverts commit 0078faa84b90e194221871c8adf27e48e20f8653, reversing
changes made to 098b93441001911d0d8a4370c89ab7531347c17e.
Merge branch '2.0'

* 2.0:
  Revert "merged branch jakzal/2.0-StaticMethodLoaderFix (PR #3937)"
  fixed CS
merged branch umpirsky/issue-3379 (PR #3922)

Commits
-------

24bd8f4 Added missing dot to translation messages.
4bff221 Added missing dot to translation messages.
7454894 Added missing dot to translation messages.
6e90c50 Updated upgrade instructions.
7e21dd1 Added missing dot to translation messages.

Discussion
----------

Issue 3379

This should fix [issues 3379](https://github.com/symfony/symfony/issues/3379)

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

by stof at 2012-04-13T15:06:32Z

Your branch conflicts with master. Please rebase it

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

by umpirsky at 2012-04-13T19:11:54Z

@stof I tried to rebase, I'm not sure if I did everything right. Is it ok now?

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

by umpirsky at 2012-04-13T19:12:06Z

@stof I tried to rebase, I'm not sure if I did everything right. Is it ok now?

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

by mvrhov at 2012-04-13T19:19:34Z

IMHO no, because there are commits from other people. Did you follow the [instructions](http://symfony.com/doc/current/contributing/code/patches.html#id1)?

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

by stof at 2012-04-13T19:36:53Z

@mvrhov commits from others ?

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

by umpirsky at 2012-04-13T19:41:53Z

@stof There were some, so I reverted. Now I'm trying again following instructions from Symfony doc.

I come to this:

```
$ git push origin issue-3379
To git@github.com:umpirsky/symfony.git
 ! [rejected]        issue-3379 -> issue-3379 (non-fast-forward)
error: failed to push some refs to 'git@github.com:umpirsky/symfony.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.
```

And I don't know how to fix this. Any idea?

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

by stof at 2012-04-13T19:43:45Z

@umpirsky when you rebase, it is logical to need to force the push

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

by umpirsky at 2012-04-13T19:44:38Z

@stof I did `git push -f origin issue-3379`. I hope it's fixed now.

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

by maoueh at 2012-04-13T20:39:34Z

@umpirsky seems better than last time I checked :)

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

by umpirsky at 2012-04-13T20:43:04Z

@maoueh Is it good enough? :)

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

by maoueh at 2012-04-13T20:51:27Z

@umpirsky At least, the rebase seems good enough :D As for the subject of the PR, I don't pronounce myself ;)

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

by vicb at 2012-04-13T20:53:23Z

you should probably squash the commits
Use Memcache::replace() first instead of Memcache::set(): http://docs.php.net/manual/en/memcache.replace.php#100023
merged branch bschussek/issue3878 (PR #3923)

Commits
-------

6e4ed9e [Form] Fixed regression: bind(null) was not converted to an empty string anymore
fcb2227 [Form] Deprecated FieldType, which has been merged into FormType
bfa7ef2 [Form] Removed obsolete exceptions
2a49449 [Form] Simplified CSRF mechanism and removed "csrf" type

Discussion
----------

[Form] Merged FieldType into FormType

Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3878
Todo: update the documentation on theming

![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3878)

This PR is a preparatory PR for #3879. See also #3878.

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

by juliendidier at 2012-04-13T14:25:19Z

What's the benefit ?

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

by henrikbjorn at 2012-04-13T14:26:40Z

why `input_widget` ? and not just `widget`

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

by Burgov at 2012-04-13T14:27:49Z

@juliendidier dynamic inheritance is now obsolete which fixes some other issues

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

by stloyd at 2012-04-13T14:37:26Z

What about __not__ breaking API so *badly* and leaving `FieldType` which will be simple like (with marking as deprecated):

```php
<?php

class FieldType extends AbstractType
{
    public function getParent(array $options)
    {
        return 'form';
    }

    public function getName()
    {
        return 'field';
    }
}

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

by bschussek at 2012-04-13T14:43:41Z

@stloyd That's a very good idea.

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

by mvrhov at 2012-04-13T17:41:21Z

IMHO what @stloyd proposed sounds like a good idea, but removing FieldType class, if #3903 will come into life might ensure that more forms will broke and people will check them thoroughly.

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

by r1pp3rj4ck at 2012-04-13T18:46:08Z

@bschussek looks great, but I'm concerned about how quickly will the third-party bundles adapt to this BC break. I hope really quick, because if they don't the whole stuff will be useless :S of course it's not your problem to solve.

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

by stof at 2012-04-13T18:50:32Z

@r1pp3rj4ck there is already another BC break requiring to update custom types for Symfony master. So third party bundles already have to do some work.

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

by r1pp3rj4ck at 2012-04-13T18:59:37Z

@stof which one? I've looked into @bschussek 's RFC about these [foo].bar stuff, but it's not yet implemented. Are you refering to this or another one I've missed?

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

by stof at 2012-04-13T19:04:06Z

@r1pp3rj4ck the change regarding default options

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

by r1pp3rj4ck at 2012-04-13T19:06:10Z

@stof oh, I forgot that one. Weird thing is that I've already changed my default options today and still forgetting these stuff :D

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

by bschussek at 2012-04-14T08:58:29Z

I restored and deprecated FieldType now. I'd appreciate further reviews.

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

by stloyd at 2012-04-14T09:02:32Z

Maybe we should try to avoid this BC in templates ? What do you think about similar move like with `FieldType` ? (hold old, but inside just render new)

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

by bschussek at 2012-04-14T09:07:22Z

@stloyd You mean for those cases where people explicitely render the block "field_*"? We can do that.

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

by stloyd at 2012-04-14T09:09:45Z

@bschussek Yes I mean this case =) Sorry for not being explicit, I need some coffee I think =)

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

by bschussek at 2012-04-17T14:45:35Z

I added the field_* blocks again for BC. Could someone please review again? Otherwise this can be merged.

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

by Burgov at 2012-04-17T15:11:16Z

@bschussek I'm not sure what has changed to cause this, but if I try out your branch on our forms, if I leave the value of an input empty, eventually the reverseTransform method receives a null value, rather than a '' (empty string) value, as on the current symfony master.

DateTimeToLocalizedStringTransformer, for example, will throw an Exception if the value is not a string

```php
if (!is_string($value)) {
   throw new UnexpectedTypeException($value, 'string');
}
```

Other than that, all forms render just the same as they do on symfony master

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

by bschussek at 2012-04-17T15:30:29Z

@Burgov Fixed.
[Finder][Comparator] not equal operator
[FrameworkBundle] Fix TraceableEventDispatcher unable to trace static class callables
merged branch drak/trace_static (PR #3977)

Commits
-------

3939c90 [FrameworkBundle] Fix TraceableEventDispatcher unable to trace static class callables

Discussion
----------

[FrameworkBundle] Fix TraceableEventDispatcher unable to trace static class callables

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
[HttpFoundation] fixed CS in ParameterBag class.
merged branch gajdaw/finder_comparator_not_equal (PR #3974)

Commits
-------

1b320c8 [Finder][Comparator] not equal operator

Discussion
----------

[Finder][Comparator] not equal operator

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
merged branch hhamon/http_foundation_cs (PR #3980)

Commits
-------

64a0abe [HttpFoundation] fixed CS in ParameterBag class.

Discussion
----------

[HttpFoundation] fixed CS in ParameterBag class.

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
[HttpFoundation] fixed phpdoc in ParameterBag::getInt() method.