Session object now implements SessionInterface to make it more portable.
AbstractSessionStorage and SessionSaveHandlerInterface now makes implementation
of session storage drivers simple and easy to write for both custom save handlers
and native php save handlers and respect the PHP session workflow.
This commit outsources the flash message processing to it's own interface.
Overall flash messages now can have multiple flash types and each type can
store multiple messages. For convenience there are now four flash types
by default, INFO, NOTICE, WARNING and ERROR.
There are two concrete implementations: one preserving the old behaviour of
flash messages expiring exactly after one page load, regardless of being
displayed or not; and the other where flash messages persist until explicitly
popped.
This commit outsources session attribute storage to it's own class.
There are two concrete implementations, one with structured namespace storage and the other
without.
Commits
-------
ac59db7 cleanup
64ea95d [WebProfilerBundle] Add redirection info to the router panel
826bd23 [FrameworkBundle] fix phpDoc of ControllerResolver::createController()
e3cf37f [HttpFoundation] RedirectResponse: add the ability to retrieve the target URL, add unit tests
50c85ae [WebProfiler] Add info to the router panel
Discussion
----------
[WIP][Profiler] Routing
former #3206 part 3 (depends on part 1 - #3280)
The goal of this PR is to fix#3264 by adding redirection infos on the router panel.
Done:
* Add info on the target url / route
To do:
* Display an accurate URL matching process (when using the RedirectableUrlMatcher)
Commits
-------
0d4d7e0 [WebProfilerBundle] Make the toolbar use the common JS
a440279 [WebProfilerBundle] Adds panel pages
762d90d [Profiler] Buid a common infrastructure
Discussion
----------
[Profiler] Provide a common infrastructure
former #3206 part 3
* base JS (provides ajax, toggle, css class helpers),
* panel pages (used only by the Doctrine panel for now).
Successfuly tested with the (future version of the) Doctrine panel.
Commits
-------
22c8f80 [Form] Fixed issues mentioned in the PR comments
3b1b570 [Form] Fixed: The "date", "time" and "datetime" types can be initialized with \DateTime objects
88ef52d [Form] Improved FormType::getDefaultOptions() to see default options defined in parent types
b9facfc [Form] Removed undefined variables in exception constructor
Discussion
----------
[Form] Fixed: "date", "time" and "datetime" fields can be initialized with \DateTime objects
Bug fix: yes
Feature addition: yes
Backwards compatibility break: **yes**
Symfony2 tests pass: yes
Fixes the following tickets: #3288
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3288)
Fixed exception that was thrown when doing:
$builder->add('createdAt', 'date', array('data' => new \DateTime()));
On a side note, the options passed to `FieldType::getDefaultOptions` now always also contain the default options of any parent types. This is necessary if you want to be independent of how `getDefaultOptions` is implemented in the parent type and still rely on the already defined values.
As a result, `FieldType::getParent` doesn't see default options anymore. This shouldn't be a big problem, because this method only relies on options in few cases. If it does, options now need to be checked for existence with `isset` before being used (BC break).
---------------------------------------------------------------------------
by bschussek at 2012-02-09T16:14:46Z
@fabpot Ready to merge.
---------------------------------------------------------------------------
by bschussek at 2012-02-10T12:15:04Z
@fabpot Ready to merge
Commits
-------
da2447e [Form] Fixed MergeCollectionListener when used with a custom property path
b56502f0 [Form] Added getParent() to PropertyPath
7e5104e [Form] Fixed MergeCollectionListener for the case that the form's data is updated by the data mapper (as happening in CollectionType)
Discussion
----------
[Form] Fixed MergeCollectionListener for the case that the form's data is updated by the data mapper
Bug fix: yes
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3293, #1499
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3293)
This fixes CollectionType to properly use adders and removers. Apart from that, adders and removers now work with custom property paths. PropertyPath was extended for a method `getParent`.
---------------------------------------------------------------------------
by bschussek at 2012-02-10T07:42:13Z
@fabpot Ready to merge.
Commits
-------
0a4519d [Form] Fixed duplicate errors on forms with "error_bubbling"=false
Discussion
----------
[Form] Fixed duplicate errors on forms with "error_bubbling"=false
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2308
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue2308)
Commits
-------
6a45a41 [Form] Fixed Form::bindRequest() when used on a form without children
Discussion
----------
[Form] Fixed Form::bindRequest() when used on a form without children
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2553
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue2553)
Commits
-------
411a0cc [Validator] Added GroupSequenceProvider to changelog
815c769 [Validator] Renamed getValidationGroups to getGroupSequence
d84a2e4 [Validator] Updated test expectations
9f2310b [Validator] Fixed typos, renamed hasGroupSequenceProvider
e0d2828 [Validator] GroupSequenceProvider tests improved, configuration changed
c3b04a3 [Validator] Changed GroupSequenceProvider implementation
6c4455f [Validator] Added GroupSequenceProvider
Discussion
----------
[Validator] Added GroupSequenceProvider
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: ![](https://secure.travis-ci.org/blogsh/symfony.png?branch=dynamic_group_sequence)
As discussed in #3114 I implemented the "GroupSequenceProvider" pattern for the validator component. It allows the user to select certain validation groups based on the current state of an object. Here is an example:
/**
* @Assert\GroupSequenceProvider("UserGroupSequnceProvider")
*/
class User
{
/**
* @Assert\NotBlank(groups={"Premium"})
*/
public function getAddress();
public function hasPremiumSubscription();
}
class UserGroupSequenceProvider implements GroupSequenceProviderInterface
{
public function getValidationGroups($user)
{
if ($user->hasPremiumSubscription()) {
return array('User', 'Premium');
} else {
return array('User');
}
}
}
With this patch there are two mechanisms to define the group sequence now. Either you can use @GroupSequence to define a static order of validation groups or you can use @GroupSequenceProvider to create dynamic validation group arrays.
The ClassMetadata therefore has methods now which implement quite similar things. The question is whether it would make sense to interpret the static group sequence as a special case and create something like a DefaultGroupSequenceProvider or StaticGroupSequenceProvider which is assigned by default. This would cause a BC break inside the validator component.
---------------------------------------------------------------------------
by bschussek at 2012-01-28T13:39:54Z
I like the implementation, but I think we should differ a little bit from Java here.
1. `GroupSequenceProviderInterface` should be implemented by the domain classes themselves (`User`), not by a separate class.
2. As such, the parameter `$object` from `getValidationGroups($object)` can be removed
3. `ClassMetadata::setGroupSequenceProvider()` should accept a boolean to activate/deactivate this functionality. Also the check for the interface (does the underlying class implement it?) should be done here
Apart from that, special cases need to be treated:
* A definition of a group sequence and a group sequence provider in the same `ClassMetadata` should not be allowed. Either of them must not be set.
* Metadata loaders must take care of settings made by parent classes. If `Animal` is extended by `Dog`, `Animal` defines a group sequence (or group sequence provider) and `Dog` a group sequence provider (or group sequence), only the setting of `Dog` should apply
---------------------------------------------------------------------------
by blogsh at 2012-01-28T21:25:37Z
Changes of the latest commit:
- GroupSequenceProviderInterface has to be implemented by the domain class
- The annotation/configuration options let the user define whether the provider is activated or not (is this neccessary at all?)
- An error is thrown if the user wants to use static group sequences and the provider simultaneously
At the moment neither the static group sequence nor the provider is inherited from parent classes or interfaces. I don't know if it would make sense to enable this feature. There could be problems if a user wants to define a static group sequence in the parent class and a sequence provider in the child class.
---------------------------------------------------------------------------
by bschussek at 2012-01-30T13:07:04Z
> There could be problems if a user wants to define a static group sequence in the parent class and a sequence provider in the child class.
In this case, the setting in the child class should override the setting of the parent class.
But we can leave this open for now. As it seems, [this issue is unresolved in Hibernate as well](https://hibernate.onjira.com/browse/HV-467).
---------------------------------------------------------------------------
by blogsh at 2012-01-30T22:54:41Z
Okay, finally I managed to upload the latest commit. If you got a bunch of notifications or so I'm sorry, but I had to revert some accidental changes in the commit :(
I've rewritten the tests and have removed the "active" setting in the XML configuration.
---------------------------------------------------------------------------
by blogsh at 2012-02-02T15:24:01Z
Okay, typos are fixed now and `hasGroupSequenceProvider` has been renamed to `isGroupSequenceProvider`. I also had to adjust some tests after the rebase with master.
---------------------------------------------------------------------------
by bschussek at 2012-02-03T09:25:19Z
Looks good.
@fabpot 👍
---------------------------------------------------------------------------
by fabpot at 2012-02-03T09:46:52Z
Can you add a note in the CHANGELOG before I merge? Thanks.
---------------------------------------------------------------------------
by blogsh at 2012-02-09T12:31:27Z
@fabpot done
Commits
-------
ba3b321 [ClassLoader] Added a class map file generator utility
Discussion
----------
[ClassLoader] Added a class map file generator utility
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2407
---------------------------------------------------------------------------
by lsmith77 at 2011-11-30T19:33:52Z
@thesalla do you have time/interest to finish this up?
---------------------------------------------------------------------------
by thesalla at 2011-12-01T09:55:50Z
sure (will attempt at least), but no sooner than tomorrow
---------------------------------------------------------------------------
by stof at 2011-12-12T20:41:41Z
@thesalla @fabpot what is the state of this PR ?
---------------------------------------------------------------------------
by thesalla at 2011-12-17T19:36:58Z
If you don't have any other suggestions or ideas, I'd consider it finished.
---------------------------------------------------------------------------
by lsmith77 at 2012-01-24T09:27:12Z
ping
---------------------------------------------------------------------------
by fabpot at 2012-02-02T08:21:38Z
@thesalla: Can you rename the ClassMapDumper class to ClassMapGenerator and then squash your commit before the merge? Thanks.
---------------------------------------------------------------------------
by thesalla at 2012-02-04T12:55:48Z
@fabpot done.
Commits
-------
928e352 Change the array access used in UniqueEntityValidator
Discussion
----------
[DoctrineBridge] Change the array access used in UniqueEntityValidator
MongoDB ODM Cursor does not implement ArrayAccess and therefor using
`$result[0]` will fail. `reset()` rewinds the array and returns the
first element value.
DoctrineMongoDBBundle#77
/cc @beberlei
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-06T08:09:25Z
Made a mistake, the findBy call would still return a cursor. Changed the findBy to findOneBy we only want one result anyway.
---------------------------------------------------------------------------
by stof at 2012-02-06T08:11:26Z
findOneBy is wrong: you will not detect duplicate anymore if you return a single element
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-06T08:28:03Z
@stof before it was only the first result that was used anyway so if it had found 3 results it would only have used the first one. Performance is apparently the biggest issue with findOneBy so this have been reverted.
---------------------------------------------------------------------------
by stof at 2012-02-06T08:31:17Z
@henrikbjorn no, we use other results too: if ``count()`` is not 1, the validation fails
---------------------------------------------------------------------------
by stof at 2012-02-06T08:36:06Z
Btw, running the testsuite would have tell you there is an issue when using findOneBy as it was breaking a test :)
---------------------------------------------------------------------------
by bschussek at 2012-02-06T10:45:44Z
Why doesn't this validator use a SELECT COUNT anyway?
---------------------------------------------------------------------------
by stof at 2012-02-06T10:57:00Z
@bschussek because we need to check if an existing value is for the same object or another one. Otherwise, the valdiation would fail as soon as you are editing an existing object without changing the unique value
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-06T11:03:40Z
@stof @bschussek other changes that should be done? Else it should be ready to be merged ?
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-06T13:00:57Z
@stof done an rebased.
---------------------------------------------------------------------------
by bschussek at 2012-02-06T13:04:44Z
👍 /cc @fabpot
Commits
-------
b65a997 [Form] Added test ChoiceList::testGetChoicesForValuesCorrectOrderingOfResult for correct ordering check
a60daff [Form] Fixed incorrect sorting in ChoiceList::getChoicesForValues
Discussion
----------
[Form] Fixed incorrect sorting in ChoiceList::getChoicesForValues
ChoiceList::getChoicesForValues return collection with sorting, that not corresponding to the sorting for input keys
---------------------------------------------------------------------------
by bschussek at 2012-02-03T21:40:49Z
Can you adapt the test cases to fail for this case please? (probably by use of assertSame instead of assertEquals in one of the existing tests)
---------------------------------------------------------------------------
by grizlik at 2012-02-04T08:41:44Z
I need to create a new test or modify an existing one?
---------------------------------------------------------------------------
by bschussek at 2012-02-04T09:58:04Z
Something like this in ChoiceListTest:
public function testGetChoicesForValuesReverseOrderedValues()
{
$values = array('2', '1');
$this->assertSame(array($this->obj3, $this->obj2), $this->list->getChoicesForValues($values));
}
Commits
-------
78c1451 [Validator] Throwing exception in ConstraintValidator::setMessage() if initialize() wasn't called
Discussion
----------
[Validator] Throwing exception in ConstraintValidator::setMessage() if initialize() wasn't called
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3269)
---------------------------------------------------------------------------
by Maks3w at 2012-02-05T09:52:21Z
One problem was that. Now I initialized the unit test with a execution
context mockup and works good.
Another problem I found is in the rules for upgrade from 2.0 to
2.1:
In v2.0: with setMessages() only one argument is mandatory ($message)
In v2.1: With the new way, addViolation(), then you need 2 arguments.
But, in v2.0 with the new way, addViolation, required 3 arguments.
So for preserve forward and backward compatibility, you need pass 3
arguments to addViolation() I think that it is helpfull and could be written in the
doc.
At the last one ¿What is the purpose of the third argument? ¿Can I pass
any object as invalid value?
Thanks
---------------------------------------------------------------------------
by bschussek at 2012-02-05T10:45:16Z
The last argument should always be the validated value that caused the constraint to fail.
Commits
-------
80682ba Fixed CS
007de8c [Tests] [Propel] Added some tests for the ModelChoiceList class
8257efd [Propel] Refactored the whole ModelChoiceList
Discussion
----------
Fix propel bridge
Ok, so I rewrote the `ModelChoiceList` based on the `EntityChoiceList`, and I provided the same test suite.
Sorry for the last PR, it was a fix to avoid fatal..
Cheers,
William
fixed cs
Small refactoring for Finder support
If class name found, return
Find multiple classes and namespaces in the same file
fixed problems with inheritance and non-php files
Renamed ClassMapDumper to ClassMapGenerator
fixed error with splfileinfo
Commits
-------
4847d3a renamed command
e97af0b code fixes
df94282 [FrameworkBundle] removed unnecessary DebugCommand
fa32885 [SecurityBundle] added configuration info
2f8ad93 [MonologBundle] added configuration info
9757958 [FrameworkBundle] added configuration info
58939f1 [TwigBundle] added configuration docs
8dc40e4 [FrameworkBundle] added config:dump console command
Discussion
----------
Config dump command
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1663
Todo: add more config info/examples
[![Build Status](https://secure.travis-ci.org/kbond/symfony.png?branch=config_dump_command)](http://travis-ci.org/kbond/symfony)
This is a config dump command based on the additions of PR #1099. This was initially part of that PR and there is some discussion there about it (https://github.com/symfony/symfony/pull/1099)
### Usage:
1. dump by root node: ``app/console config:dump framework``
2. dump by bundle name: ``app/console config:dump FrameworkBundle``
A few issues/notes:
* Only dumps to yaml
* Only 1 configuration per bundle (this was brought by @stof here: https://github.com/symfony/symfony/pull/1099#issuecomment-1242993)
* Works out of the box for most bundles but not ones that use a non-standard ``Configuration`` class (such as the assetic bundle). In this case ``Extension::getConfiguration()`` must be configurated.
I have used it to create some (most) of the config reference docs. It works fine but I find it somewhat crude, any suggestions to improve it would be appreciated.
---------------------------------------------------------------------------
by kbond at 2012-01-24T21:00:43Z
Few more issues:
1. Should I abstract the logic to a "normalizer" class that converts the Configuration class into a manageable array? I struggle with this idea because isn't that what ``TreeBuilder`` basically is?
2. @stof made a good point that ``config:dump`` doesn't really describe what this does. Would dumping your config be useful? Perhaps ``config:dump framework`` dumps the config for your project while ``config:dump --ref framework`` dumps the default reference?
---------------------------------------------------------------------------
by stof at 2012-01-24T21:18:15Z
@kbond you cannot really dump the config. Part of it does not go through these extensions at all. And it does not make much sense anyway IMO.
the command as is does the right job IMO (i.e. dumping a reference for the extension). But its name should be improved
---------------------------------------------------------------------------
by kbond at 2012-01-24T21:20:51Z
``config:reference`` perhaps?
---------------------------------------------------------------------------
by fabpot at 2012-02-02T10:05:19Z
This command is about displaying the default configuration for a given bundle. So, what about `config:dump-reference`? As I understand, the command name is the last element to figure out before merging, right?
---------------------------------------------------------------------------
by stof at 2012-02-02T10:19:49Z
@fabpot indeed.
---------------------------------------------------------------------------
by stof at 2012-02-02T10:34:16Z
and +1 for ``config:dump-reference``
---------------------------------------------------------------------------
by Tobion at 2012-02-02T12:08:03Z
why not use the words you chose yourself: `config:dump-default`
I think it's more explicit.
Commits
-------
8321593 [Form] DRYed ChoiceType
0753cee [Form] Fixed read_only attribute for expanded fields
Discussion
----------
[Form] Fixed read_only attribute for expanded fields
Expanded choice widgets lose the knowledge of read_only attribute value.
Fixes bug introduced by #3193
---------------------------------------------------------------------------
by helmer at 2012-02-02T16:24:50Z
Please hold before merging, @bschussek had some thoughts about my changes in ``ChoiceType``, waiting for feedback.
---------------------------------------------------------------------------
by bschussek at 2012-02-02T16:33:12Z
I'm fine with the refactoring then, but please split it into two commits at least. The changes in ChoiceType have nothing in common with the actual issue here.
---------------------------------------------------------------------------
by helmer at 2012-02-02T19:40:39Z
Tests added.
---------------------------------------------------------------------------
by bschussek at 2012-02-03T10:14:32Z
Great, thanks.
@fabpot 👍
Commits
-------
8714d79 [Form] Simplified code in MergeCollectionListener
8ab982a [Form] Fixed: Custom add and remove method are not invoked if disallowed
02f61ad [Form] Renamed choice and collection options "adder_prefix" and "remover_prefix" to "add_method" and "remove_method" and allowed to specify full method names
b393774 [Form] Used direct method access in MergeCollectionListener instead of Reflection to avoid problems when using class hierarchies
d208f4e [Form] Made it possible to use models with only either addXxx() or removeXxx()
Discussion
----------
[Form] Fixed edge cases in MergeCollectionListener
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3239)
Fixes an issue mentioned in the comments of #3239
see https://github.com/symfony/symfony/pull/3239#issuecomment-3776312
---------------------------------------------------------------------------
by bschussek at 2012-02-02T12:12:17Z
Wait a minute before merging this.
---------------------------------------------------------------------------
by bschussek at 2012-02-02T13:01:55Z
@fabpot Ready to merge
Commits
-------
9b0245b [Form] Made prefix of adder and remover method configurable. Adders and removers are not called if "by_reference" is disabled.
49d1464 [Form] Implemented MergeCollectionListener which calls addXxx() and removeXxx() in your model if found
7837f50 [Form] Added FormUtil::singularify()
Discussion
----------
[Form] Forms now call addXxx() and removeXxx() in your model
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1540
Todo: adapt documentation
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue1540)
Adds functionality for calling `addXxx` and `removeXxx` method in your model. All types returning a collection of values are affected: "collection", "choice" (with multiple selection) and "entity" (with multiple selection).
Example:
class Article
{
public function addTag($tag) { ... }
public function removeTag($tag) { ... }
public function getTags($tag) { ... }
}
And the controller:
$form = $this->createFormBuilder($article)
->add('tags')
->getForm();
Upon modifying the form, addTag() and removeTag() are now called appropiately.
---------------------------------------------------------------------------
by stof at 2012-02-01T18:23:49Z
Really great
---------------------------------------------------------------------------
by vicb at 2012-02-01T18:24:04Z
Great !!
Two suggestions:
* make "add" and "remove" configurable,
* introduce a base class for the remove listeners with (final?) `::getSubscribedEvents()` and `::getEventPriorities()`
---------------------------------------------------------------------------
by haswalt at 2012-02-01T18:57:46Z
+1 this
---------------------------------------------------------------------------
by daFish at 2012-02-01T19:54:46Z
+1
---------------------------------------------------------------------------
by michelsalib at 2012-02-01T20:55:37Z
Can wait to have it!
It will save lots of time trying to solve WTF effects and making workarounds.
---------------------------------------------------------------------------
by bschussek at 2012-02-02T09:37:12Z
@vicb: Your first point is done. The second, I don't understand.
---------------------------------------------------------------------------
by stof at 2012-02-02T09:40:50Z
@bschussek your branch conflicts with master according to github
---------------------------------------------------------------------------
by vicb at 2012-02-02T09:52:40Z
@bschussek my point is that I can stand hard-coded priorities which are error prone. A better solution might be to introduce constants (in `FormEvents` / `FormEventPriorities` ?) with meaningful names.
---------------------------------------------------------------------------
by bschussek at 2012-02-02T10:21:52Z
@stof Rebased
@vicb I know, but who is responsible for managing priorities? There is no central entitty that can do this. (btw this is a general problem of the priority system of the EventDispatcher)
@fabpot Ready to merge.
---------------------------------------------------------------------------
by vicb at 2012-02-02T10:23:28Z
@bschussek doesn't each form has is own dispatcher so there is no need for a global registry here, something local to the form could be good enough.
The listener is used by the Collection type as well as the Choice and Entity type (with multiple
selection). The effect is that you can have for example this model:
class Article
{
public function addTag($tag) { ... }
public function removeTag($tag) { ... }
public function getTags($tag) { ... }
}
You can create a form for the article with a field "tags" of either type "collection" or "choice"
(or "entity"). The field will correctly use the three methods of the model for displaying and
editing tags.
Commits
-------
2e4ebe4 [Validator] Renamed methods addViolationAtRelativePath() and getAbsolutePropertyPath() in ExecutionContext
9153f0e [Validator] Deprecated ConstraintValidator methods setMessage(), getMessageTemplate() and getMessageParameters()
0417282 [Validator] Fixed typos
a30a679 [Validator] Made ExecutionContext immutable and introduced new class GlobalExecutionContext
fe85bbd [Validator] Simplified ExecutionContext::addViolation(), added ExecutionContext::addViolationAt()
f77fd41 [Form] Fixed typos
1fc615c Fixed string access by curly brace to bracket
a103c28 [Validator] The Collection constraint adds "missing" and "extra" errors to the individual fields now
f904a9e [Validator] Fixed: GraphWalker does not add constraint violation if error message is empty
1dd302c [Validator] Fixed ConstraintViolationList::__toString() to not include dots in the output if the root is empty
1678a3d [Validator] Fixed: Validator::validateValue() propagates empty validation root instead of the provided value
Discussion
----------
[Validator] Improved "missing" and "extra" errors of Collection constraint
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2615
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue2615)
Instead of a single violation
Array:
The fields "foo", "bar" are missing
various violations are now generated.
Array[foo]:
This field is missing
Array[bar]:
This field is missing
Apart from that, the PR contains various minor fixes to the Validator.
---------------------------------------------------------------------------
by bschussek at 2012-02-02T09:14:52Z
@fabpot Ready for merge.
Commits
-------
7cecb4e [Form] added support for parent of FormBuilder
Discussion
----------
[Form] added support for parent of FormBuilder
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
In some cases of building forms, it is good to know the attributes of the parent builder. In my case I want to automaticaly add the subscriber to the fields, whose parent builder has a concrete attribute.
Replace #2882
Commits
-------
e9b4c58 [Console] Enable process isolantion in Shell
Discussion
----------
[Console] Enable process isolantion in Shell
Bug fix: no
BC break: no
Feature addition: yes
Symfony2 test pass: yes
Fixes the following tickets: #2848#2847
Todo: Write unit tests
See tickets for reference, need help with unit testing, because I don't know how to test this :)
---------------------------------------------------------------------------
by canni at 2011-12-16T09:36:32Z
I've tested this with different scenarios like "inception" (invoking shell from shell - will not work) ;) and others, everything seems to work great.
As I have no idea on how to pack this with unit testing some help needed, also as I don't have any windows in home ;) need someone to test it on MS os.
And we should decide, do we want process isolation by default? (This will not break the BC, break only the "expected behavior" - colorful output and "interactivity")
---------------------------------------------------------------------------
by canni at 2011-12-18T15:14:26Z
I've rebased this branch to match current `HEAD` and I've added usage of new process builder, for better portability an shell arg escaping.
---------------------------------------------------------------------------
by fabpot at 2012-02-02T08:28:32Z
@canni: Can you squash your commits before I merge this PR? Thanks.
---------------------------------------------------------------------------
by canni at 2012-02-02T09:07:16Z
@fabpot @stof done.
Bug fix: no
BC break: no
Feature addition: yes
Symfony2 test pass: yes
Fixes the following tickets: #2848#2847
Todo: -
See tickets for reference, need help with testing, because I don't know how to test this :)
Commits
-------
de253dd [Form] read_only and disabled attributes
Discussion
----------
[Form] read_only and disabled attributes (closes#1974)
1. Removed ``readOnly`` property from ``Form``, as it is no longer required
2. Introduced ``disabled`` property to ``Form``, behaves exactly like ``readOnly`` used to
3. Added ``disabled`` property to fields, defaults to ``false``, renders as ``disabled="disabled"``
4. A field with positive ``read_only`` property now renders as ``readonly="readonly"``
---------------------------------------------------------------------------
by helmer at 2012-01-26T17:46:17Z
I changed ``Form`` and ``FormBuilder`` property ``readOnly`` to ``disabled``. On second thought, this is perhaps not such good change - while readOnly somewhat implied the use-case, disabled no longer does.
Perhaps something else, like ``bindable`` (as not to confuse with read_only attribute of Fields)?
@bschussek, others, any thoughts?
---------------------------------------------------------------------------
by bschussek at 2012-01-31T06:53:59Z
Please prefix commits with the affected component, if applicable.
---------------------------------------------------------------------------
by helmer at 2012-01-31T08:41:03Z
@bschussek Prefixed. Please also see see to [this question](https://github.com/symfony/symfony/pull/3193#issuecomment-3673074)
Commits
-------
6090dee [FormType] Adopted MoneyTypeTest::testMoneyPatternWorksForYen to CS
e814d27 [FormType] Fixed broken MoneyType regexp for JPY
Discussion
----------
[Bugfix][Form] Fixed broken MoneyType regexp for JPY
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: ![Build Status](https://secure.travis-ci.org/ManuelKiessling/symfony.png?branch=ticket_3124) Fixes the following tickets: #3124
Todo: -
The regexp in MoneyType doesn't work if currency format has no decimal
(like JPY) and doesn't work either if the currency symbol is unicode
This change fixes both issues and adds a unit test
Commits
-------
601d462 [Form] Added getValidators() to Form class
Discussion
----------
[Form] Added getValidators() to Form class
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
I am working implementing client side validation in a bundle that adds validation rules via a form builder. I am currently unable to pull the validators from the Form class which is making the implementation incredibly difficult.
I noticed that the transformers are currently exposed and based on some feedback I got on IRC I am guessing these weren't exposed simply because no one needed them at the time.
---------------------------------------------------------------------------
by mlively at 2011-12-28T20:54:41Z
Side note: It would be incredibly helpful to have this in the current branch of symfony. I implemented it on master because it is a new feature, but I would be more than happy to patch it into 2.0 if you would like.
---------------------------------------------------------------------------
by canni at 2012-01-11T10:15:46Z
👍
As this is new feature it cannot fit into 2.0 series, but 2.1 is just few clicks ahead, maybe this feature will fit into ;)
---------------------------------------------------------------------------
by bschussek at 2012-01-31T08:23:05Z
ping @fabpot
👍
---------------------------------------------------------------------------
by stof at 2012-01-31T08:51:26Z
@mlively could you rebase your branch ? it conflicts with the current master
---------------------------------------------------------------------------
by mlively at 2012-01-31T21:38:39Z
Yes, I can do that might be later today.
Commits
-------
2374e54 Break paths in exceptions hard with css if necessary
Discussion
----------
Exceptions: Break source-paths with CSS
Sometimes in exceptions absolute paths of files are pretty long and need more than one line.
eg.: `/Volumes/Macintosh HD/Users/blabla/Sites/project/files/src/SomeProjectsName/SomeProjectsNameFrontendBundle/Controller/CreateController.php`
This should be displayed within the width of the `h1`.
Using CSS `word-break: break-all;`.
Commits
-------
b228942 fix for entity choice list when ->loaded is false and the class name is an entity shorthand name and updated tests to work with refactored choicelist
Discussion
----------
fix for entity choice list when ->loaded is false and the class name is ...
...an entity shorthand name
This bug was reintroduced after the latest choicelist refactoring and was originally fixed in 231e79ce0f
---------------------------------------------------------------------------
by stof at 2012-02-01T15:17:37Z
Please also add a unit test for this to avoid further regressions
---------------------------------------------------------------------------
by stof at 2012-02-01T17:05:31Z
btw, a better fix would be to put the real class name in ``$this->class`` to avoid doing it each time (you are doing it in a loop btw). We don't need to keep the short notation anyway
---------------------------------------------------------------------------
by Burgov at 2012-02-01T17:19:01Z
@stof done, thanks for the comments
Commits
-------
4bc0c67 [HttpFoundation] fix a small copy and paste error
Discussion
----------
Just a small copy and paste error...
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
Todo:
Commits
-------
7b79cc2 Fixing typo in XLIFF Dumper
Discussion
----------
Fixing typo in XLIFF Dumper
There was a typo in the service name for the XLIFF Dumper
A new ExecutionContext is now created everytime that GraphWalker::walkConstraint() is
launched. Because of this, a validator B launched from within a validator A can't break
A anymore by changing the context.
Because we have a new ExecutionContext for every constraint validation, there is no point
in modifying its state anymore. Because of this it is now immutable.
Commits
-------
57cc531 [Form] Improved PHPDocs of choice lists
9e7e2af [Form] Fixed PHPDoc: Used {@inheritdoc} where applicable
2c530cc Fixed typos in UPGRADE file
7899bea Added examples to UPGRADE
d346ae6 Improved choice list sections of UPGRADE and CHANGELOG
a676598 [Form] Added class LazyChoiceList
Discussion
----------
[Form] Added LazyChoiceList
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3156)
Adds a ChoiceList implementation that satisfies people who formerly extended ArrayChoiceList and loaded choices lazily in its `load` method.
---------------------------------------------------------------------------
by craue at 2012-01-30T12:56:49Z
👍
---------------------------------------------------------------------------
by craue at 2012-01-30T14:55:38Z
Not sure if it's a bug in this PR or in #3156, but the labels get replaced by their keys:
```php
<?php
use Symfony\Component\Form\Extension\Core\ChoiceList\ChoiceList;
use Symfony\Component\Form\Extension\Core\ChoiceList\LazyChoiceList;
use Symfony\Component\Form\Extension\Core\ChoiceList\SimpleChoiceList;
class MyChoiceList extends LazyChoiceList {
protected function loadChoiceList() {
$choices = array(
'bla' => 'blaaaaaahhhh',
);
return new SimpleChoiceList($choices, array(), ChoiceList::COPY_CHOICE, ChoiceList::COPY_CHOICE);
}
public function getChoices() {
$choices = parent::getChoices();
// $choices is array('bla' => 'bla')
return $choices;
}
}
```
If it's not this PR, I can of course open a new ticket for that. But I'm only working with `LazyChoiceList`s.
---------------------------------------------------------------------------
by stof at 2012-01-30T16:07:41Z
@craue the ``SimpleChoiceList`` is an implementation using the same string as label and value. If you need different ones, you need to use the ``ChoiceList`` implementation.
---------------------------------------------------------------------------
by craue at 2012-01-30T16:22:06Z
@stof: That would make `SimpleChoiceList` useless for almost any case. Are you sure?
---------------------------------------------------------------------------
by craue at 2012-01-30T16:33:31Z
The bug even occurs when using
```
return new ChoiceList(array_keys($choices), array_values($choices), array(), ChoiceList::COPY_CHOICE, ChoiceList::COPY_CHOICE);
```
---------------------------------------------------------------------------
by stof at 2012-01-30T16:40:19Z
well, the SimpleChoiceList is for simple cases (thus its naming) where you want the same for the label and the values. And if you look at the class, you will see it extends the ChoiceList implementation which is the generic one.
---------------------------------------------------------------------------
by craue at 2012-01-30T16:53:36Z
For me, "simple" would mean that it just takes the array given, using keys as indices and values as labels. No fancy stuff messing around with anything. :D But, is there anything wrong in this code or in mine? @bschussek: Please enlighten me.
---------------------------------------------------------------------------
by bschussek at 2012-01-30T17:16:58Z
You are both wrong :) `getChoices` does not return the choices with their associated labels anymore. What you get now are the choice indices as array keys and the choice values as array values. How both are determined depends on the index and value generation strategy, which, in your case, are both COPY_CHOICE.
The difference between simple and complex choice lists is, that simple choice lists can only contain scalar values as choices, while other choice lists (such as ObjectChoiceList, EntityChoiceList) may contain objects as choices.
Choice labels are now stored in ChoiceView objects, which are returned by the various `get*Views` methods.
---------------------------------------------------------------------------
by craue at 2012-01-30T18:07:43Z
It's pretty annoying having provided an array with keys and values when initializing the `ChoiceList` but being unable to retrieve it again. Guess I just over-used or even abused those choice lists as kind of (not only form related) lookup tables.
---------------------------------------------------------------------------
by bschussek at 2012-01-30T19:27:21Z
@craue: What's your use case?
---------------------------------------------------------------------------
by craue at 2012-01-30T20:10:16Z
I just used choice lists extensively, even for not directly form-related stuff. In one case, I'm using two of them (which are also used individually) to build up a third one. That went well using the old `ArrayChoiceList`s and their `getChoices` method. Just thinking about creating another set of model classes which just contain my lists. So for only one select field in a form it'll take three classes then: (A) a list, (B) a choice list based on A, (C) a choice form type based on B. Oh well ... :D
---------------------------------------------------------------------------
by craue at 2012-01-30T21:31:32Z
Anyway, this PR for `LazyChoiceList` is great, so please merge it. ;)
---------------------------------------------------------------------------
by craue at 2012-01-31T14:00:46Z
@bschussek: Is it ready to be merged?
---------------------------------------------------------------------------
by bschussek at 2012-01-31T16:59:17Z
Yes
Commits
-------
9db6c8d print info about environment and debug mode when running the `CacheWarmupCommand`
Discussion
----------
print info about environment and debug mode when running the `CacheWarmupCommand`
Adapted from `CacheClearCommand`. Replaces #3212.
Commits
-------
8dc78bd [Form] Fixed YODA issues
600cec7 [Form] Added missing entries to CHANGELOG and UPGRADE
b154f7c [Form] Fixed docblock and unneeded use statement
399af27 [Form] Implemented checks to assert that values and indices generated in choice lists match their requirements
5f6f75c [Form] Fixed outstanding issues mentioned in the PR
7c70976 [Form] Fixed text in UPGRADE file
c26b47a [Form] Made query parameter name generated by ORMQueryBuilderLoader unique
18f92cd [Form] Fixed double choice fixing
f533ef0 [Form] Added ChoiceView class for passing choice-related data to the view
d72900e [Form] Incorporated changes suggested in PR comments
28d2f6d Removed duplicated lines from UPGRADE file
e1fc5a5 [Form] Restricted form names to specific characters to (1) fix generation of HTML IDs and to (2) avoid problems with property paths.
87b16e7 [Form] Greatly improved ChoiceListInterface and all of its implementations
Discussion
----------
[Form] Improved ChoiceList implementation and made form naming more restrictive
Bug fix: yes
Feature addition: yes
Backwards compatibility break: **yes**
Symfony2 tests pass: yes
Fixes the following tickets: #2869, #3021, #1919, #3153
Todo: adapt documentation
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue1919)
The changes in this PR are primarily motivated by the fact that invalid form/field names lead to various problems.
1. When a name contains any characters that are not permitted in HTML "id" attributes, these are invalid
2. When a name contains periods ("."), form validation is broken, because they confuse the property path resolution
3. Since choices in expanded choice fields are directly translated to field names, choices applying to either 1. or 2. lead to problems. But choices should be unrestricted.
4. Unless a choice field is not expanded and does not allow multiple selection, it is not possible to use empty strings as choices, which might be desirable in some occasions.
The solution to these problems is to
* Restrict form names to disallow unpermitted characters (solves 1. and 2.)
* Generate integer indices to be stored in the HTML "id" and "name" attributes and map them to the choices (solves 3.). Can be reverted to the old behaviour by setting the option "index_generation" to ChoiceList::COPY_CHOICE
* Generate integer values to be stored in the HTML "value" attribute and map them to the choices (solves 4.). Can be reverted to the old behaviour by setting the option "value_generation" to ChoiceList::COPY_CHOICE
Apart from these fixes, it is now possible to write more flexible choice lists. One of these is `ObjectChoiceList`, which allows to use objects as choices and is bundled in the core. `EntityChoiceList` has been made an extension of this class.
$form = $this->createFormBuilder()
->add('object', 'choice', array(
'choice_list' => new ObjectChoiceList(
array($obj1, $obj2, $obj3, $obj4),
// property path determining the choice label (optional)
'name',
// preferred choices (optional)
array($obj2, $obj3),
// property path for object grouping (optional)
'category',
// property path for value generation (optional)
'id',
// property path for index generation (optional)
'id'
)
))
->getForm()
;
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-19T18:09:09Z
Rather than passing `choices` and a `choice_labels` arrays to the view would it make sense to introduce a `ChoiceView` class and pass one array of objects?
---------------------------------------------------------------------------
by stof at 2012-01-22T15:32:36Z
@bschussek can you update your PR according to the feedback (and rebase it as it conflicts according to github) ?
---------------------------------------------------------------------------
by bschussek at 2012-01-24T00:15:42Z
@kriswallsmith fixed
Fixed all outstanding issues. Would be glad if someone could review again, otherwise this PR is ready to merge.
---------------------------------------------------------------------------
by fabpot at 2012-01-25T15:17:59Z
Is it ready to be merged?
---------------------------------------------------------------------------
by Tobion at 2012-01-25T15:35:50Z
Yes I think so. He said it's ready to be merged when reviewed.
---------------------------------------------------------------------------
by bschussek at 2012-01-26T02:30:36Z
Yes.
---------------------------------------------------------------------------
by bschussek at 2012-01-28T12:39:00Z
Fixed outstanding issues. Ready for merge.
Commits
-------
a52c675 [WebProfilerBundle] Improve the logger panel
Discussion
----------
[WebProfilerBundle] Improve the logger panel
No more need to hit 'refresh'
Commits
-------
b177786 Make twig optimizations configurable
Discussion
----------
optimizations not configurable
Valid option for twig but missing in the configuration. I am currently hardsetting this in my own bundle.
Commits
-------
b879397 [Profiler] Optimize time panel IS
d4300b9 [WebProfilerBundle] Tweak the time view
416a2a4 [Stopwatch] Fix some logic
8c3505e [Profiler] Tweak PHPDoc
3bcd154 [HttpKernel] Tweak the Profile class - DRY
Discussion
----------
[Profiler] Stopwatch related tweaks
* Some fixes in the stopwatch logic,
* Some JS fixes,
* Make use of modern JS.
The regexp in MoneyType doesn't work if currency format has no decimal
(like JPY) and doesn't work either if the currency symbol is unicode
This change fixes both issues and adds a unit test
Commits
-------
ed9c348 Authentication(Success|Failure)Handler can now return null
Discussion
----------
[Security] Authentication(Success|Failure)Handler can now return null
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Related to the following ticket: #838
[![Build Status](https://secure.travis-ci.org/odolbeau/symfony.png)](http://travis-ci.org/odolbeau/symfony)
Correct me if I'm wrong but for now it's not possible to handle Authentication(Success|Failure) in some case only (for example to handle XmlHttpRequest on login form).
With this change, if the handler return null, the default behavior is kept.
---------------------------------------------------------------------------
by stof at 2012-01-24T17:28:49Z
👍
Commits
-------
43e0db5 [DomCrawler] Add support for multivalued form fields (fix#1579, #3012)
Discussion
----------
[DomCrawler] Support for multivalued fields
This is a tentative fix for #1579 by @kriswallsmith, also see #3012 for more info.
Any feedback is appreciated.
---------------------------------------------------------------------------
by vicb at 2012-01-05T08:44:51Z
@stof thanks for the valuable feedback I think most of it should be implemented should we use this solution.
The one thing I don't agree is PSR-0, I don't want this class to be public, that's is just a "private" helper class.
There are also missing type hints in the helper class, that should be added.
---------------------------------------------------------------------------
by alessandro1997 at 2012-01-05T10:05:15Z
Well, @vicb, I think it's up to the developer to not use "private" classes. Just write it in the documentation. But declaring two classes in the same file would be a big violation of the standards.
---------------------------------------------------------------------------
by vicb at 2012-01-05T11:28:53Z
What "standard"s ?
PSR-0 is about auto-loading, I don't want/need this to be autoloaded.
Sf coding standards ? Well relying on a developer reading the doc is more error prone than the current implementation. I sometimes favor pragmatism over theory.
edit: I am not trying to say I am right here but only that I don't see any added value in moving the helper class to a dedicated file. I appreciate any feedback, really.
---------------------------------------------------------------------------
by fabpot at 2012-01-06T11:55:09Z
FYI, we already have such a "private" class in https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener.php#L135
---------------------------------------------------------------------------
by vicb at 2012-01-06T16:36:04Z
@alessandro1997 if you need an example on why it is not safe to rely on developers reading comments, see #2892
---------------------------------------------------------------------------
by vicb at 2012-01-09T22:19:52Z
@fabpot I am waiting for your feedback on the [proposed API](https://github.com/symfony/symfony/pull/3035/files#L1R57) before finishing this PR.
---------------------------------------------------------------------------
by drak at 2012-01-10T05:12:16Z
@fabpot
> FYI, we already have such a "private" class in https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener.php#L135
Why on is that necessary, it could just be another class file in the namespace. Unless you are making some kind of forward compatibility, e.g. for with a new class in PHP 5.4 then I see no reason to do that.
---------------------------------------------------------------------------
by vicb at 2012-01-10T07:40:32Z
What would be a good reason not to allow "private" classes ?
If the Sf coding standards are the only good reason let's change them then.
[Java](http://stackoverflow.com/questions/968347/can-a-java-file-have-more-than-one-class) and [ActionScript3](http://livedocs.adobe.com/flex/3/html/help.html?content=03_Language_and_Syntax_05.html) allow such construction
I would no say any better than the above link on Stack Overflow:
> The purpose of including multiple classes in one source file is to bundle related support functionality (internal data structures, support classes, etc) together with the main public class. Note that it is always ok not to do this -- the only effect is on the readability (or not) of your code.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T09:35:09Z
There are also many private classes in the test cases.
---------------------------------------------------------------------------
by stof at 2012-01-10T13:29:08Z
@Tobion for tests, it is logical because there is no autoloader for the test classes.
---------------------------------------------------------------------------
by vicb at 2012-01-10T13:31:53Z
@stof by definition you do not want a "private" class to be autoloaded anyway.
---------------------------------------------------------------------------
by alessandro1997 at 2012-01-10T14:11:42Z
Sure, but what you're doing here is just making instantiating the class a bit more difficult. If a stubborn developer wants to use it, then he (or her) can include the file manually or autoload the "main class".
PHP does NOT have support for private/inner classes, and, until it does, all classes should be istantiable normally.
---------------------------------------------------------------------------
by stof at 2012-01-10T14:23:30Z
@vicb what about someone wanting to serialize the object ? (well, serializing is not the issue. unserializing is)
---------------------------------------------------------------------------
by vicb at 2012-01-10T14:57:52Z
@alessandro1997 you are absolutely right, it's not meant to be instantiated from the outside (it's **private**). You could argue the same with private properties & methods (using Reflection). Dead-end.
@stof Is unserializing really an issue as the file would have been loaded already ?
---------------------------------------------------------------------------
by fabpot at 2012-01-22T09:38:13Z
@vicb: I'm fine with the proposed API, but I fail to see why it would be more BC than #3012.
---------------------------------------------------------------------------
by vicb at 2012-01-22T10:06:56Z
For BC I have to check #3012 again but at some point if I remember correctly the public API had changed (not sure about the latest version in your branch)
By introducing the private helper class, it is quite easy to see that the public API is not modified by this PR.
Next steps:
* Stof the code,
* Add/fix phpdoc,
* Add tests for the helper class,
* Add/refactor tests for the `Form` class.
@fabpot if you agree with the above steps it could be ready sometime next week.
---------------------------------------------------------------------------
by fabpot at 2012-01-22T10:21:16Z
The API is perhaps not changed but the behavior will certainly changed. I agree with your steps.
---------------------------------------------------------------------------
by vicb at 2012-01-22T10:45:10Z
Which leads to the question: should we consider this as a change in behavior (2.1) or a bug fix (2.0) ?
_I am thinking of a form with multiple fields named `field[]`_
---------------------------------------------------------------------------
by fabpot at 2012-01-22T11:32:04Z
@vicb: this change should be done on master
---------------------------------------------------------------------------
by vicb at 2012-01-24T07:59:40Z
Should be ready now, let me know when I should squash after review.
---------------------------------------------------------------------------
by fabpot at 2012-01-24T08:18:03Z
@vicb: yes, can you squash your commits?
---------------------------------------------------------------------------
by vicb at 2012-01-24T08:29:58Z
@fabpot done
ad (1): HTML4 "id" attributes are limited to strings starting with a letter and containing only letters, digits, underscores, hyphens, periods and colons.
ad (2): Property paths contain three special characters needed for correct parsing: left/right bracket and period.
The rules for form naming are:
* Names may start with a letter, a digit or an underscore. Leading digits or underscores will be stripped from the "id" attributes.
* Names must only contain letters, digits, underscores, hyphens and colons.
* Root forms may have an empty name.
Solves #1919 and #3021 on a wider scope.
Commits
-------
e37783f [DoctrineBridge] Refactored the query sanitization in the collector
3b260d2 Refactored the collector to separate the loggers per connection
Discussion
----------
Doctrine collector
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes (for the end user, it will require deleting old profiler data)
Symfony2 tests pass: yes ![Build Status](https://secure.travis-ci.org/stof/symfony.png?branch=doctrine_collector)
This refactors the Doctrine collector to allow implementing doctrine/DoctrineBundle#7
The first commit splits the logging of queries per connection to be able to know which connection was used instead of using a shared stack.
The second commit refactors the sanitation of the parameters to apply the DBAL conversion and then keep the param whenever possible (i.e. when we are sure it is serializable). Such queries will then be explainable in the profiler as we will be able to use the parameters again. Due to the way PDO works, the only cases where we would get an unexplainable queries due to the parameters are queries using a LOB parameter (as it is a resource) or broken queries (passing an object to PDO for instance). And this second case does not make sense to explain the query of course.
---------------------------------------------------------------------------
by stof at 2012-01-23T12:32:16Z
Merging this PR should be synchronized with the DoctrineBundle PR due to the BC break in the collector
Commits
-------
4a797df Oracle issues
81d73bb Oracle issues
2316b21 Oracle issues
315bfc4 just update
b20b15b Oracle 10 issues
Discussion
----------
Oracle issues
updated with some adjustments required by stof
---------------------------------------------------------------------------
by fabpot at 2011-12-13T07:24:12Z
@schmittjoh: Can you have a look at this PR?
---------------------------------------------------------------------------
by fabpot at 2011-12-24T08:19:37Z
Can you squash your commit before I merge your PR? Thanks.
Commits
-------
753c067 [FrameworkBundle] added $view['form']->csrfToken() helper
e1aced8 [Twig] added {{ csrf_token() }} helper
Discussion
----------
[Twig] [FrameworkBundle] added CSRF token helper
I've added a templating helper and Twig function for generating a CSRF token without the overhead of creating a form.
```html+jinja
<form action="{{ path('user_delete', { 'id': user.id }) }}" method="post">
<input type="hidden" name="_method" value="delete">
<input type="hidden" name="_token" value="{{ csrf_token('delete_user_' ~ user.id) }}">
<button type="submit">delete</button>
</form>
```
```php
<?php
class UserController extends Controller
{
public function delete(User $user, Request $request)
{
$csrfProvider = $this->get('form.csrf_provider');
if (!$csrfProvider->isCsrfTokenValid('delete_user_'.$user->getId(), $request->request->get('_token')) {
throw new RuntimeException('CSRF attack detected.');
}
// etc...
}
}
```
The test that is failing on Travis appears to be unrelated, but I may be wrong?
```
1) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testLoginLogoutProcedure with data set #1 ('de')
RuntimeException: OUTPUT:
Catchable fatal error: Argument 3 passed to Symfony\Bundle\FrameworkBundle\Controller\TraceableControllerResolver::__construct() must be an instance of Symfony\Component\HttpKernel\Debug\Stopwatch, instance of Symfony\Bundle\FrameworkBundle\Controller\ControllerNameParser given, called in /tmp/2.1.0-DEV/StandardFormLogin/cache/securitybundletest/appSecuritybundletestDebugProjectContainer.php on line 94 and defined in /home/vagrant/builds/kriswallsmith/symfony/src/Symfony/Bundle/FrameworkBundle/Controller/TraceableControllerResolver.php on line 37
```
---------------------------------------------------------------------------
by pablodip at 2012-01-10T14:18:45Z
As you don't need forms to use the csrf provider, how about putting its service without the form prefix? It could even make sense to put the CsrfProvider as a component since you can use it standalone and in more cases than only forms. It would be a small component though.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T17:54:14Z
I think it would be more clear to generate the token in the controller. Doing so in the template will spread the CSRF intention across template and controller. So I don't think this extension is necessary.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T17:58:14Z
@pablodip I'm open to the idea of a Csrf component. This would be a good place for some nonce classes as well.
@Tobion I disagree. One use case is for a list of users, each with a delete form. Iterating over the users in the controller and generating a token for each, just to iterate over them again in the view is a waste and adds complexity.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T18:05:14Z
I see. But I don't understand why the intention needs to be different for each user to delete. Usually the intention is the same for each form type. I thought this is enough.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T18:06:13Z
Yes, a static intention would suffice.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T18:07:08Z
Then your use case is not valid anymore.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T18:12:25Z
I would suggest to make a cookbook article out of it about how to create a simple form without the form component.
And include such things as validating the result using the validator component and checking the CSRF.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T21:32:50Z
This helper makes it easier to use CSRF protection without a form and we should make it as easy as possible. Spreading the intention across controller and template is not concerning to me. Either way, a cookbook entry is a great idea.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T21:47:12Z
Well, it's just one line more without this helper. So I disagree it makes it really easier when you know how to use the CsrfProvider which is a pre-condition anyway since you must still validate its correctness by hand.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-13T13:24:15Z
Another use case is when rendering a page with a bunch of simple buttons with different intentions: delete user, delete comment, follow, unfollow... Creating all of these in the controller just leads to spaghetti.
---------------------------------------------------------------------------
by jwage at 2012-01-17T21:55:53Z
👍 lots of use cases for something like this @OpenSky
Commits
-------
92f820a Renamed registerConstraints to loadDynamicValidatorMetadata
dd12ff8 CS fix, getConstraints renamed
09c1911 [Validator] Improved dynamic constraints
54cb6e4 [Validator] Added dynamic constraints
Discussion
----------
[Validator] Dynamic constraints
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
By now the Validator component is based on a per-class configuration of
constraints, but in some cases it might be neccessary to add new constraints
dynamically at runtime.
This pull request adds a "ConstraintProviderInterface" to the Validator component. If an object is validated that implements this interface the method "getConstraints" is used to add dynamic constraints:
class User implements ConstraintProviderInterface
{
protected $isPremium;
protected $paymentInformation;
public function getConstraints(ClassMetadata $metadata)
{
if ($this->isPremium) {
$metadata->addPropertyConstraint('paymentInformation', new NotBlank());
}
}
}
---------------------------------------------------------------------------
by alexandresalome at 2012-01-15T11:20:04Z
Related to #1151
---------------------------------------------------------------------------
by canni at 2012-01-16T09:22:28Z
👍
---------------------------------------------------------------------------
by bschussek at 2012-01-16T12:32:44Z
I think this is a good addition. I think we still have a naming problem though. When constraints are loaded using a static method, the default name for the loader method is `loadValidatorMetadata`. Since the method for dynamic constraint loading is basically the same, I think the two names should be related.
Solution (1): Rename the method in your interface to `loadDynamicValidatorMetadata`. Ugly and long.
class MyClass implements ConstraintProviderInterface
{
public static loadValidatorMetadata(ClassMetadata $metadata) ...
public loadDynamicValidatorMetadata(ClassMetadata $metadata) ...
}
Solution (2): Rename the default method name in `StaticMethodLoader` to `registerConstraints` and adjust the docs. Breaks BC.
class MyClass implements ConstraintProviderInterface
{
public static registerConstraints(ClassMetadata $metadata) ...
public registerDynamicConstraints(ClassMetadata $metadata) ...
}
@fabpot: Are we allowed to break BC here? If not, we should probably stick to (1).
---------------------------------------------------------------------------
by fabpot at 2012-01-16T12:36:14Z
I would prefer to not break BC if possible.
---------------------------------------------------------------------------
by blogsh at 2012-01-16T15:25:46Z
So "loadDynamicValidatorMetadata" would be the best solution?
---------------------------------------------------------------------------
by althaus at 2012-01-17T13:39:19Z
>So "loadDynamicValidatorMetadata" would be the best solution?
Sounds fine for me based on @bschussek's comment.
Commits
-------
9cb513f Now… no more tabs!
7f34643 [Pull Request 3134] Improved code based on comments
90abc0f [Serializer][XmlEncoder] add CDATA padding only if necessary
Discussion
----------
[Serializer][XmlEncoder] add CDATA padding only if necessary
Changed XML encoder so CDATA padding is only added to value if necessary.
---------------------------------------------------------------------------
by fabpot at 2012-01-17T21:34:59Z
You should add some unit tests.
Commits
-------
0b7e2e0 Support for DELETE method in forms
Discussion
----------
[Form] Support DELETE HTTP verb
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: none
Todo: -
As `Symfony\Component\HttpFoundation\Request` already support DELETE requests nicely by parsing the request for us, support for the HTTPs DELETE verb can be easily done.
---------------------------------------------------------------------------
by mvrhov at 2012-01-20T06:00:49Z
This is wrong. The body for DELETE method is supposed to be empty or if present ignored.
Also the DELETE is supposed to remove the resource identified by uri, so the same code as for GET should be executed.
---------------------------------------------------------------------------
by lstrojny at 2012-01-20T08:56:22Z
I don’t think that’s the case. The HTTP standard does not state explicitly that DELETE does not have a body. See this [StackOverflow thread](http://stackoverflow.com/questions/2539394/rest-http-delete-and-parameters)
Commits
-------
9e55cda Only call recover() when spool is a Swift_FileSpool
d2a0c74 Use if/else instead of ternary operator
15c666b Add a "recover-timeout" option to allow recovering messages that have taken too long to send
Discussion
----------
[SwiftmailerBundle] Add a "recover-timeout" option to swiftmailer:spool:send
This would allow for easy resending of messages that were marked as being sent, but for whatever reason were never actually sent.
Commits
-------
f6b3ea2 New validation messages and translated to Serbian language.
Discussion
----------
New validation messages and translated to Serbian language.
It would be nice for translators to be notified somehow when new validation messages appear. I copied those from French translation, not sure if that is the right way to go?
Also, in addition, I would like to contribute sr@latin translation. To explain, Serbian language have dual alphabet, both cyrillic and latin. I'm not sure if Symfony locale supports locale variants? Can you suggest right translation file name for this?
---------------------------------------------------------------------------
by stof at 2012-01-21T19:20:31Z
Please send the ids up to 41 to the 2.0 branch. Only 42 and above are new in 2.1
---------------------------------------------------------------------------
by stof at 2012-01-21T19:23:48Z
Regarding serbian latin translations, there is an issue here: both cyrillic and latin serbian share the same locale id ``sr_SP``
---------------------------------------------------------------------------
by stof at 2012-01-21T19:33:01Z
ok, looking a bit more about it, it seems like the right way to handle this is to use ``sr_Latn`` and ``sr_Cyrl`` for the 2 variants
---------------------------------------------------------------------------
by umpirsky at 2012-01-21T20:28:37Z
But ids 42 and above can be merged to master (2.1), right?
I think they share `sr_RS`, not `sr_SP` as you said.
So, `validators.sr.xlf` should be renamed to `validators.sr_Cyrl.xlf` and for latig added `validators.sr_Latn.xlf`?
---------------------------------------------------------------------------
by stof at 2012-01-21T21:00:18Z
yeah, but previous ids should be merged in 2.0 first to avoid merge conflicts later
---------------------------------------------------------------------------
by umpirsky at 2012-01-21T22:37:15Z
Done https://github.com/symfony/symfony/pull/3168
* 2.0:
Updated Serbian translation.
fixed CS
[Locale][Testing] Fixed breaking tests if 'intl' extension is not installed (#3139)
[Bridge] [Twig] fixed typo in a comment of the Twig FormExtension extension.
Commits
-------
0513eb1 [Form] Pass translation domain to the sub-forms when choice list is expanded
Discussion
----------
[Form] Pass translation domain to the sub-forms when choice list is expanded
* Bug fix: yes
* Tests pass: yes
* Feature addition: no
* BC compatibility break: no
When you have a select list with ``translation_domain``, you loose translations by expanding the list.
---------------------------------------------------------------------------
by stof at 2012-01-21T14:55:31Z
👍
---------------------------------------------------------------------------
by fabpot at 2012-01-21T16:51:17Z
Why not doing that in the 2.0 branch instead?
---------------------------------------------------------------------------
by stof at 2012-01-21T17:26:32Z
@fabpot because the support of translation domains is a 2.1 feature
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This is cleanup after enabling empty form names, now form with empty name
will not render the default `id="form"` container attribute.
Developers can extend/override this behaviour by standard form theming methods.
Commits
-------
7e14a56 [Locale] Removed unneccesary semi-colon
cacc880 [Bugfix][Locale] Fixed incomplete Locale data loading
Discussion
----------
[Bugfix][Locale] Fixed incomplete Locale data loading
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: ![Build Status](https://secure.travis-ci.org/ManuelKiessling/symfony.png) Fixes the following tickets: #3090
Todo: -
Sublocales like de_CH returned only incomplete results for
getDisplayCountries(), getDisplayLanguages() and getDisplayLocales(),
consisting only of results specific for this sublocale, but without the
results of their respective parent locale
This PR was https://github.com/symfony/symfony/pull/3106 before - reopened it as a new PR because the commits were too chaotic.
Commits
-------
e6e3da5 [Validator] Improved test coverage of CollectionValidator and reduced test code duplication
509c7bf [Validator] Moved Optional and Required constraints to dedicated sub namespace.
bf59018 [Validator] Removed @api-tag from Optional and Required constraint, since these two are new.
6641f3e [Validator] Added constraints Optional and Required for the CollectionValidator
Discussion
----------
[Validator] Improve support for optional/required fields in Collection constraint
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: none
Todo: none
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=collection-validator)
Improves the `Collection` constraint to test on a more granular level if entries of the collection are optional or required. Before this could only be set using the "allowExtraFields" and "allowMissingFields" options, but these are very general and limited.
The former syntax - without Optional or Required - is still supported.
Usage:
$array = array(
'name' => 'Bernhard',
'birthdate' => '1970-01-01',
);
$validator->validate($array, null, new Collection(array(
'name' => new Required(),
'birthdate' => new Optional(),
));
// you can also pass additional constraints for the fields
$validator->validate($array, null, new Collection(array(
'name' => new Required(array(
new Type('string'),
new MinLength(3),
)),
'birthdate' => new Optional(new Date()),
));
---------------------------------------------------------------------------
by canni at 2012-01-15T20:22:17Z
@bschussek I've rewritten a lot of test code for Collection validator in 2.0 branch and also had modified validator itself, as it had a bug #3078, consider waiting with this PR till fabpot will merge 2.0 back into master, as there will be code conflicts :)
---------------------------------------------------------------------------
by Koc at 2012-01-15T23:13:04Z
Does it helps to #2615 ?
---------------------------------------------------------------------------
by fabpot at 2012-01-16T06:44:53Z
@canni: I've just merged 2.0 into master.
---------------------------------------------------------------------------
by bschussek at 2012-01-16T12:05:19Z
@fabpot: Rebased. I also fixed the CS issues mentioned by @stof.
Commits
-------
f3c413d add missing class var; add phpdocs
Discussion
----------
add missing class var; add phpdocs
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
---------------------------------------------------------------------------
by fabpot at 2012-01-16T11:12:27Z
We don't document properties, especially private ones.
---------------------------------------------------------------------------
by vicb at 2012-01-16T11:20:44Z
Good doc always help and should be accepted even for private properties.
However sometimes doc isn't necessary: `The digest algorithm to use` does not bring more information than the name itself `MessageDigestPasswordEncoder::algorithm`, the `@var` annotation could be useful - even more for objects & arrays.
---------------------------------------------------------------------------
by gimler at 2012-01-16T11:37:54Z
i have remove the private property comments.
Sublocales like de_CH returned only incomplete results for
getDisplayCountries(), getDisplayLanguages() and getDisplayLocales(),
consisting only of results specific for this sublocale, but without the
results of their respective parent locale
Commits
-------
7961014 [Yaml][Parser] changes according review
efce640 [Yaml][Parser] throw an exception if not readable
Discussion
----------
[Yaml][Parser] throw an exception if service file not readable.
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3077
Todo: -
---------------------------------------------------------------------------
by makasim at 2012-01-13T15:49:49Z
@fabpot done
Commits
-------
e23d452 Add info about BC Break to CHANGELOG-2.1
d7ffeb5 Add some more tests, and enforce boolean return value of interface implementations.
9d3a49f When method name is `hasUserChanged` the return boolean should be true (to match question semantics) and false when user has not changed, this commits inverts return statements.
c57b528 Add note about `AdvancedUserInterface`.
3682f62 Refactor `isUserChanged` to `hasUserChanged`
56db4a1 Change names to Equatable
680b108 Suggested fixes ;)
9386583 [BC Break][Security] Moved user comparsion logic out of UserInterface As discussed on IRC meetings and in PR #2669 I came up with implementation. This is option2, I think more elegant.
Discussion
----------
[BC Break][Security][Option2] Moved user comparsion logic out of UserInterface
As discussed on IRC meetings and in PR #2669 I came up with implementation.
This is option2, I think more elegant.
BC break: yes
Feature addition: no/feature move
Symfony2 test pass: yes
Symfony2 test written: yes
Todo: decide about naming
[![Build Status](https://secure.travis-ci.org/canni/symfony.png)](http://travis-ci.org/canni/symfony)
---------------------------------------------------------------------------
by schmittjoh at 2011-12-19T19:33:24Z
This looks much better than the previous PR. Thanks!
One thing, we also discussed this on Doctrine, the name "comparable" is used in most programming languages to perform a real compare operation that is ">", "<", or "=". In this case though, we are specifically interested in equality of two objects (we cannot establish a natural order between these objects). Java has no such interface as all objects naturally have an equals() method, .NET uses "Equatable" which looks a bit odd. Not sure if there are better names.
---------------------------------------------------------------------------
by canni at 2011-12-19T19:34:52Z
I think this is best of "both worlds" we have nice full-featured implementation suitable for most, and if someone needs advanced compare logic just implements interface. @stof @schmittjoh, what do you think?
---------------------------------------------------------------------------
by stof at 2011-12-19T19:36:55Z
@canni I already commented on the code, and I agree with @schmittjoh that the naming can be confusing
---------------------------------------------------------------------------
by jmikola at 2011-12-20T17:33:22Z
I don't mean to bikeshed, but I strongly agree with @schmittjoh about implications of "compare". I'm not concerned with the interface name so much as I am with `compareUser()`. Given that this method returns a boolean, I think it's best to prefix it with `is` (e.g. `isSameUser`, `isUserEqualTo`) or `equals` (e.g. `equalsUser`).
In this PR, the Token class is implementing the interface, so I think having "User" in the method name is a good idea. Naturally, if the interface was intended for User classes, we could do without it.
---------------------------------------------------------------------------
by canni at 2011-12-20T19:00:00Z
@jmikola in this PR Token class does not implement any additional interface, and `compareUser` is `private` and used internally. I don't stand still after this names, I'll update PR as soon as some decision about naming will be done.
---------------------------------------------------------------------------
by jmikola at 2011-12-21T02:29:59Z
@canni: My mistake, I got confused between the Token method and interface method, which you've since renamed in canni/symfony@fcfcd1087b.
---------------------------------------------------------------------------
by mvrhov at 2011-12-21T06:09:45Z
hm. Now I'm going to bike shed. Wouldn't the proper function name be hasUserChanged?
---------------------------------------------------------------------------
by stof at 2011-12-21T10:58:38Z
it would probably be bettter. The meaning of ``true`` and ``false`` would then be the opposite of the current ones but this is not an issue IMO as it is a different method
---------------------------------------------------------------------------
by jstout24 at 2011-12-27T18:08:49Z
@canni nice job
---------------------------------------------------------------------------
by fabpot at 2011-12-30T14:59:11Z
The method `isUserChanged()` must be rename. What about `hasUserChanged()` as @mvrhov suggested or `isUserDifferent()`?
---------------------------------------------------------------------------
by canni at 2012-01-02T11:44:05Z
@fabpot done.
---------------------------------------------------------------------------
by fabpot at 2012-01-02T18:13:40Z
The only missing thing I can think of is adding some unit tests.
---------------------------------------------------------------------------
by canni at 2012-01-10T20:16:25Z
@fabpot is there anything more you think that should done in this PR?
---------------------------------------------------------------------------
by stof at 2012-01-10T20:38:46Z
@canni can you rebase your branch ? it conflicts with the current master according to github
---------------------------------------------------------------------------
by canni at 2012-01-10T20:56:55Z
@stof done.
---------------------------------------------------------------------------
by fabpot at 2012-01-12T18:06:00Z
@canni: Can you just add some information in the CHANGELOG and in the UPGRADE file? That's all I need to merge this PR now. Thanks a lot.
---------------------------------------------------------------------------
by canni at 2012-01-12T18:16:32Z
@fabpot done, and no problem :)
Commits
-------
78ce60c Add config as required
10b3cde [FrameworkBundle] Add missing dependency and recommended libraries fixes#3094
Discussion
----------
[FrameworkBundle] Add missing dependency and recommended libraries
Fixes#3094
---------------------------------------------------------------------------
by fabpot at 2012-01-12T17:31:14Z
You forgot the dependency on config? Is it on purpose
---------------------------------------------------------------------------
by henrikbjorn at 2012-01-12T17:39:20Z
the config is recommended package on the DependencyInjection component.
---------------------------------------------------------------------------
by stof at 2012-01-12T17:40:56Z
@henrikbjorn yeah, but it is *required* dependency for FrameworkBundle, not only recommended
---------------------------------------------------------------------------
by henrikbjorn at 2012-01-12T17:41:56Z
well it will install it by default as it is recommended.
---------------------------------------------------------------------------
by stof at 2012-01-12T17:43:05Z
@henrikbjorn yeah, but it will be skipped if the user asks to avoid recommended packages (the flag is not implemented yet IIRC) which would break FrameworkBundle as it requires the component
Commits
-------
fe62401 optimized string starts with checks
Discussion
----------
optimized string starts with checks
Doing this with strpos() is slightly faster than substr().
```
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
---------------------------------------------------------------------------
by vicb at 2012-01-11T19:58:27Z
How faster ? even if the string is long and do not contain an occurrence of the sub-string ?
Looks like micro-(not)-optimizations to me.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-11T20:04:26Z
The difference is about 0.1s when repeated 1M times.
---------------------------------------------------------------------------
by vicb at 2012-01-11T20:08:12Z
% would be better (machine & env independant), what string size, what match offset ?
I personally vote against (`substr` is more meaningful to me and I do not like micro-optims)
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-11T20:12:34Z
I personally consider this a coding standard but don't want to bikeshed here :)
---------------------------------------------------------------------------
by vicb at 2012-01-11T20:28:08Z
I have [tried](https://gist.github.com/1596588) at home.
`strpos ` **is** faster unless you have a very long string, probably because you do not need to create a new string, interesting, thanks for the tip.
---------------------------------------------------------------------------
by Tobion at 2012-01-11T22:40:18Z
I think strpos() is more useful. Say you want to change the string you have to replace 2 variables (the text and the length parameter) when using substr(). It could also introduce bugs when they don't match. With strpos() it's only the text.
---------------------------------------------------------------------------
by robocoder at 2012-01-11T22:43:22Z
alternate micro-optimization that doesn't create a temporary string:
```
strncmp($v, "@", 1) === 0
```
---------------------------------------------------------------------------
by Tobion at 2012-01-11T22:47:12Z
@robocoder probably the fastest solution but needs to be benchmarked
Commits
-------
7f7f82a [HttpKernel] removed unnecessary regex
Discussion
----------
[HttpKernel] removed unnecessary regex
The pattern was also flawed because of the unescaped `.`
```
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
Commits
-------
7f7c2a7 Add prof-of-concept test, this test will fail without changes in previous commit
253eeba [BugFix][Validator] Fix for PHP incosistent behaviour of ArrayAccess
Discussion
----------
[BugFix][Validator] Fix for PHP incosistent behaviour of ArrayAccess
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2779
Todo: -
[![Build Status](https://secure.travis-ci.org/canni/symfony.png)](http://travis-ci.org/canni/symfony)
Because PHP function `array_key_exists` is buggy, it works great with native
PHP `ArrayObject` instances, but hand written implementations of `ArrayAccess`
and `Traversable` objects will fail to work with `CollectionValidator`
Tests from second commit are valid use cases, but without this change, they will fail.
Commits
-------
aa58330 [Form] fixed flawed condition
Discussion
----------
[Form] fixed flawed condition
The validate() method always returns an object. The test is whether there are violations in that object.
```
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
---------------------------------------------------------------------------
by fabpot at 2012-01-10T21:22:10Z
What about removing the if condition altogether?
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T21:23:55Z
This way we avoid creating an `ArrayIterator` for no reason.
Commits
-------
c0ad1ac [HttpKernel] Minor fixes in the Stopwatch
Discussion
----------
[HttpKernel] Minor fixes in the Stopwatch
Not a breakthrough, fixing `'0'` handling at 2 places, some re factoring (fluid interface)
As discussed on IRC meetings and in PR #2669 I came up with implementation.
This is option2, I think more elegant.
BC break: yes
Feature addition: no/feature move
Symfony2 test pass: yes
Symfony2 test written: yes
Todo: feedback needed
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2779
Todo: -
Because PHP function `array_key_exists` is buggy, it works great with native
PHP `ArrayObject` instances, but hand written implementations of `ArrayAccess`
and `Traversable` objects will fail to work with `CollectionValidator`
Commits
-------
af32590 [FrameworkBundle] Use only _route_params to generate redirect routes
Discussion
----------
[FrameworkBundle] Use only _route_params to generate redirect routes
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Routes in RedirectController are generated using all request attributes, which is inconvenient since I abuse request attributes to store other things (device types and such) relevant to the app. It renders the RedirectController useless since it adds unrelated query parameters to URLs it creates.
Commits
-------
c8bafcf Updated validators.sk.xlf file
Discussion
----------
[FrameworkBundle] Slovak translations updated
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by stof at 2012-01-09T20:33:53Z
can you send the ids below 41 to the 2.0 branch ? Only 42-28 are new for 2.1
---------------------------------------------------------------------------
by pulzarraider at 2012-01-09T20:39:42Z
Done, see #3073.
fix CS
fix CS + remove unneeded else
add documentation, change protected methods as private
rename var
throw exception for invalid name, index fix
memcache profiler storage support added, fix CS and minor bugs
fix CS
removed unneeded else
- memcached support added
- improved performance (serialization, index)
updated code to last version of Profiler
Commits
-------
c7ab9ba [Console] Allow redefinition of application options descriptions
Discussion
----------
[Console] Allow redefinition of application options descriptions
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
This allows you to redefine an `InputOption` as long as it keeps the same semantic (same default, same name, same alias, same modes). There are two purposes:
- Modifying the description with a more accurate one
- Making sure the option appears in your commands' help
Concrete example: I often want to provide a verbose version of commands. It's an elegant and very common pattern, but I basically can't document what is going to happen if you do `--verbose` since the base Application already defines `--verbose`. Also the `--verbose` option does not appear when you do `console <command> --help`, which means people probably won't think of using that option.