The WebProcessor can now be registered as a kernel.request listener to
get the request instead of passing it as a constructor argument, which
was broken as the request is not yet available when the logger is
instantiated.
Commits
-------
e344609 [DependencyInjection] Fixed composer.json
1aa0786 [FrameworkBundle] Fixed composer.json
3601f61 [DoctrineBridge] Fixed composer.json
Discussion
----------
Fix composer json
---------------------------------------------------------------------------
by jalliot at 2012-04-22T14:22:24Z
`suggest` no longer requires a version constraint. While you're at it, maybe you could change those to more meaningful strings explaining what each optional dependency provides.
---------------------------------------------------------------------------
by willdurand at 2012-04-22T14:24:27Z
I know, but the version is fine. It's more up to @fabpot to add description in each `suggest` entries.
Anyway, this is not the purpose of this PR. If you want to contribute on that, feel free :)
Commits
-------
01ca0ad [Propel1] Added security layer
Discussion
----------
[Propel1] Added security layer
Fixed the security layer for Propel 1.6, and Symfony2 2.1.
The PropelBundle is ready to go: https://github.com/propelorm/PropelBundle/pull/139
Unit tests are part of the PropelBundle at the moment, as it requires to setup a quick builder.
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
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.
Commits
-------
5208bbe [Validator] Fixed typo, updated CHANGELOG and UPGRADE
dc059ab [Validator] Added default validate() implementation to ConstraintValidator for BC
6336d93 [Validator] Renamed ConstraintValidatorInterface::isValid() to validate() because of the lack of a return value
46f0393 [Validator] Removed return value from ConstraintValidatorInterface::isValid()
Discussion
----------
[Validator] Renamed ConstraintValidatorInterface::isValid() to validate() and removed return value
Bug fix: no
Feature addition: no
Backwards compatibility break: **YES**
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: update the documentation
Before I begin, this PR is up for discussion.
I removed the return value of ConstraintValidator::isValid() because it wasn't used anymore within the framework. Removing it also means a simplification for userland implementations. Already now the validation component only depended on violation errors being present for deciding whether the validation was considered failed or not.
Because the name `isValid` does not make a lot of sense without a return value, I changed it to `validate`. Note that this affects an interface (ConstraintValidatorInterface) previously marked with `@api` by us!
What do you think about this change?
---------------------------------------------------------------------------
by stof at 2012-02-09T17:51:38Z
@bschussek IIRC, the Validator component was part of the components that are not considered as stable for 2.0 (there is 4 of them IIRC, including Config, Security and Form) so changing the interface should not be an issue here
---------------------------------------------------------------------------
by lsmith77 at 2012-02-09T17:54:55Z
No it was .. form wasn't:
http://symfony.com/doc/2.0/book/stable_api.html
---------------------------------------------------------------------------
by rdohms at 2012-02-10T13:23:32Z
I fail to see the value of the BC in this case.
Just because the framework does not use given functionality anymore is not reason to drop it, since all of this was clearly proposed as a "component" to be used in other projects. Other implementations of validator in other projects might actually depend on this.
Is it possible to just add a new value and have both functionalities available?
---------------------------------------------------------------------------
by stof at 2012-02-10T13:25:12Z
@rdohms the point is that the return value is confusing. Someone may return ``false`` by thinking it will mark the field as invalid (which is implied by the name ``isValid``) whereas it is not the case at all
---------------------------------------------------------------------------
by bschussek at 2012-02-10T13:30:13Z
Exactly. UniqueEntityValidator for example always returned `true` and nobody ever noticed.
---------------------------------------------------------------------------
by beberlei at 2012-02-10T13:53:03Z
@bschussek but its not a bug, setting the execution context failure is enough. returning false would lead to a second error message being evicted. This is the weird problem of the API imho
---------------------------------------------------------------------------
by bschussek at 2012-02-10T13:54:49Z
@beberlei This has already been fixed.
---------------------------------------------------------------------------
by stof at 2012-02-10T13:59:59Z
@beberlei in the master branch, errors are not duplicated anymore as the return value is simply ignored.
---------------------------------------------------------------------------
by Tobion at 2012-02-10T14:29:03Z
I'm +1. If people are concerned about this strong BC break we could maybe add a fallback for the majority.
Most people propably have extended the ConstraintValidator and not used the interface directly. So we can change the Interface and at the same time provide a default proxy method in ConstraintValidator for validate. I.e.
public function validate($value, Constraint $constraint)
{
$this->isValid($value, $constraint);
}
Thus all people who have extended ConstraintValidator won't notice a BC break.
---------------------------------------------------------------------------
by hades200082 at 2012-02-10T16:10:31Z
Could you not have both validate and isValid as separate methods with distinct purposes?
---------------------------------------------------------------------------
by stof at 2012-02-10T16:55:12Z
@hades200082 which distinct purposes ?
---------------------------------------------------------------------------
by hades200082 at 2012-02-10T17:02:57Z
One should actually validate. The other should return whether it is valid or not as a bool.
Even if isValid calls validate to determine this surely they are distinct purposes? doing it this way would not require a break to BC but the existing components in the framework could be switched to use validate.
---------------------------------------------------------------------------
by bschussek at 2012-02-10T17:10:50Z
@hades200082 Validators are stateless. They don't "remember" whether they validated successfully or not.
---------------------------------------------------------------------------
by hades200082 at 2012-02-10T17:13:25Z
Maybe they should? Would save revalidating every time
---------------------------------------------------------------------------
by stof at 2012-02-10T17:16:10Z
@hades200082 how could they be stateless ? you can use the same instance to validate several values. For instance, the UniqueEntityValidator is a service and so will be reused.
---------------------------------------------------------------------------
by fabpot at 2012-02-11T23:40:09Z
I would really like that we do not break BC in this case.
---------------------------------------------------------------------------
by stof at 2012-02-11T23:59:02Z
@fabpot there is also a BC break in the previous changes: the return value has no meaning at all now (it is not even considered by the GraphWalker.
Most 2.0 validator will continue working because of the new implementation of setMessage but I can provide the 2 broken cases:
```php
<?php
/**
* This validator always set the message, even when it is valid to keep things simple.
* This works fine in 2.0.x (as the return value is what makes the decision) but will
* add a violation in 2.1 (setMessage adds the violation to keep things working for
* cases setting the message only for invalid values, like the core used to do).
*/
public function isValid($value, Constraint $constraint)
{
$this->setMessage($constraint->message);
return true;
}
/**
* This validator never set the message, failing with an empty message.
* This works fine in 2.0.x (as the return value is what makes the decision) but will
* not add the violation in 2.1.
*/
public function isValid($value, Constraint $constraint)
{
return false;
}
```
The second one is clearly an edge case as it would absolutely not be user-friendly but the first one makes totally sense when using the 2.0.x API (with a boolean expression using the value of course)
---------------------------------------------------------------------------
by fabpot at 2012-02-12T00:11:19Z
I agree with you; I should probably have refused to merge the previous PR. And I think we need to reconsider this change. If not, why are we even bothering tagging stuff with the @api tag?
---------------------------------------------------------------------------
by bschussek at 2012-02-12T10:15:55Z
@stof I disagree with you. Setting an error message but not letting the validation fail is not how the API is supposed to work. Also the opposite was not meant to work, as it results in empty error messages. The third example is that a validator *had* to return true if it called `addViolation` directly. These cases show that the previous implementation was clearly buggy and needed to be fixed.
This PR is only a consequence that cleans the API up.
@fabpot IMHO validator was too young and not tried enough to be marked as stable. But as we can't change this anymore, I think the decision we have to make is
* BC/reliance on `@api` marks vs.
* API usability (also considering the coming LTR)
---------------------------------------------------------------------------
by bschussek at 2012-02-12T10:18:12Z
BTW @Tobion's suggestion could definitely make a transition easier.
---------------------------------------------------------------------------
by fabpot at 2012-02-15T10:26:10Z
@bschussek +1 for @Tobion's suggestion.
---------------------------------------------------------------------------
by Brouznouf at 2012-02-15T16:06:12Z
Could be nice to comment function as deprecated and/or trigger a E_USER_DEPRECATED error when using this method to prevent user calling this method.
---------------------------------------------------------------------------
by stof at 2012-02-15T16:09:37Z
trigger E_USER_DEPRECATED would be wrong as the kernel set the error reporting to ``-1`` and registers an error handler tuning all reported errors to exception in debug mode, so it would be a BC break.
Commenting the function as deprecated in indeed possible
---------------------------------------------------------------------------
by rdohms at 2012-02-29T11:15:01Z
Went back to working on validators and it really makes me disagree with these changes a little more. Let me explain.
In the isValid method, i like to work with return early checks, so straight up i check some stuff and return early either true/false.
From the frameworks perspective true/false does not make a difference, but from a reader's perspective it adds a lot of value:
if ($object->getId() === null) {
return true;
}
versus
if ($object->getId() === null) {
return;
}
having the return true make it clear that in this case the object is valid for anyone who is reading my validator. i think this is a good practice to push forward.
Anyway, my 2 cents on it.
---------------------------------------------------------------------------
by stof at 2012-04-04T00:05:09Z
@fabpot what do you think about this ?
---------------------------------------------------------------------------
by bschussek at 2012-04-05T16:37:38Z
@rdohms: Still, how do you want to deal with the fact that the return value is ignored anyway?
---------------------------------------------------------------------------
by rdohms at 2012-04-06T06:51:07Z
@bschussek Nobody has to know? I would keep it as it is, i have noticed that returning false without any error messages does not get me the expected results, so it seems there is no harm in keeping the parctice of true/false even if it is misleading.
Other then that.. i would alter the code to self create a error message if false is returned, thus making true/false still work, but i'm guessing that's not what your vision says, even if i find it les readable and understandable. So yeah, just my opinioin.
---------------------------------------------------------------------------
by bschussek at 2012-04-06T07:02:53Z
@rdohms: Your opinion is appreciated. Self-creation of error messages is what we did before, unfortunately it's very hacky then to suppress the self-creation if you want to return false and add (potentially more than one) error messages yourself.
---------------------------------------------------------------------------
by bschussek at 2012-04-17T14:58:07Z
I added @Tobion's suggestion now. Can you please review again? Otherwise this is ready for merge.
---------------------------------------------------------------------------
by Tobion at 2012-04-17T15:05:16Z
Statement in changelog and upgrade is missing, or?
Commits
-------
8329087 [Form] Moved calculation of ChoiceType options to closures
5adec19 [Form] Fixed typos
cb87ccb [Form] Failing test for empty_data option BC break
b733045 [Form] Fixed option support in Form component
Discussion
----------
[Form] Fixed option support in Form component
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3354, #3512, #3685, #3694
Todo: -
This PR also introduces a new helper `DefaultOptions` for solving option graphs. It accepts default options to be defined on various layers of your class hierarchy. These options can then be merged with the options passed by the user. This is called *resolving*.
The important feature of this utility is that it lets you define *lazy options*. Lazy options are specified using closures that are evaluated when resolving and thus have access to the resolved values of other (potentially lazy) options. The class detects cyclic option dependencies and fails with an exception in this case.
For more information, check the inline documentation of the `DefaultOptions` class and the UPGRADE file.
@fabpot: Might this be worth a separate component? (in total the utility consists of five classes with two associated tests)
---------------------------------------------------------------------------
by beberlei at 2012-04-05T08:54:10Z
"The important feature of this utility is that it lets you define lazy options. Lazy options are specified using closures"
What about options that are closures? are those differentiated?
---------------------------------------------------------------------------
by bschussek at 2012-04-05T08:57:35Z
@beberlei Yes. Closures for lazy options receive a Symfony\Component\Form\Options instance as first argument. All other closures are interpreted as normal values.
---------------------------------------------------------------------------
by stof at 2012-04-05T11:09:49Z
I'm wondering if these classes should go in the Config component. My issue with it is that it would add a required dependency to the Config component and that the Config component mixes many different things in it already (the loader part, the resource part, the definition part...)
---------------------------------------------------------------------------
by sstok at 2012-04-06T13:36:36Z
Sharing the Options class would be great, and its more then one class so why not give it its own Component folder?
Filesystem is just one class, and that has its own folder.
Great job on the class bschussek 👏
---------------------------------------------------------------------------
by bschussek at 2012-04-10T12:32:34Z
@fabpot Any input?
---------------------------------------------------------------------------
by bschussek at 2012-04-10T13:54:13Z
@fabpot Apart from the decision about the final location of DefaultOptions et al., could you merge this soon? This would make my work a bit easier since this one is a blocker.
---------------------------------------------------------------------------
by fabpot at 2012-04-10T18:08:18Z
@bschussek: Can you rebase on master? I will merge afterwards. Thanks.
Commits
-------
f9a486e [Validator] Added support for pluralization of the SizeLengthValidator
c0715f1 [FrameworkBundle], [TwigBundle] added support for form error message pluralization
7a6376e [Form] added support for error message pluralization
345981f [Validator] added support for plural messages
Discussion
----------
[Validator] Added support for plural error messages
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Todo: create translations for en and update others (FrameworkBundle)
[](http://travis-ci.org/hason/symfony)
---------------------------------------------------------------------------
by fabpot at 2011-05-14T20:41:01Z
@bschussek: What's your opinion?
---------------------------------------------------------------------------
by stof at 2011-09-04T13:14:29Z
@hason could you rebase your branch on top of master and update the PR ?
You also need to change the messages in the constraint that uses the pluralization to a pluralized format.
---------------------------------------------------------------------------
by stof at 2011-10-16T18:06:22Z
@hason ping
---------------------------------------------------------------------------
by stof at 2011-11-11T14:58:19Z
@hason ping again
---------------------------------------------------------------------------
by stof at 2011-12-12T20:39:10Z
@hason ping again. Can you update your PR ?
---------------------------------------------------------------------------
by hason at 2011-12-12T21:29:14Z
@stof I hope that I will update PR this week.
---------------------------------------------------------------------------
by bschussek at 2012-01-15T19:07:32Z
Looks good to me.
---------------------------------------------------------------------------
by canni at 2012-02-02T17:28:54Z
@hason can you update this PR and squash commits, it conflicts with current master
---------------------------------------------------------------------------
by hason at 2012-02-09T07:21:41Z
@stof, @canni Rebased.
What is the best solution for the translation of messages?
1. Change messages in the classes and all xliff files?
2. Keep messages in the classes and change all xliff files?
---------------------------------------------------------------------------
by stof at 2012-02-09T08:19:41Z
The constraints contain the en message so you will need to modify them to update the message
---------------------------------------------------------------------------
by hason at 2012-02-09T08:55:55Z
I prefer second option. The Validator component should be decoupled from the Translation component. The constraints contain the en message which is also the key for Translation component. We should create validators.en.xlf in the FrameworkBundle for en message. I think that this is better solution. What do you think?
---------------------------------------------------------------------------
by stof at 2012-04-04T02:22:02Z
@hason Please rebase your branch. It conflicts with master because of the move of the tests
@fabpot ping
Commits
-------
65aa387 [Form] Fixed index generation in EntityChoiceList if ID is not an integer
Discussion
----------
[Form] Fixed index generation in EntityChoiceList if ID is not an integer
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3635
Todo: -
Commits
-------
a430f3d [#3446] [Form] Fix getChoicesForValues of EntityChoiceList on empty values
Discussion
----------
[Form] Fix reverseTransform on multiple entity form type
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3446, #3727
Todo: -
---------------------------------------------------------------------------
by stof at 2012-04-03T23:05:55Z
@bschussek ping
---------------------------------------------------------------------------
by stof at 2012-04-03T23:06:45Z
This is an alternate implementation for #3727
---------------------------------------------------------------------------
by chmielot at 2012-04-04T13:47:27Z
OK, this is another possibility to fix this issue with working tests. What do you think about this?
---------------------------------------------------------------------------
by chmielot at 2012-04-04T13:51:27Z
OK, just done.
---------------------------------------------------------------------------
by stof at 2012-04-04T13:51:39Z
@beberlei @bschussek ping
---------------------------------------------------------------------------
by bschussek at 2012-04-06T18:50:37Z
@fabpot 👍
This TwigEngine implements the interface available in the component.
the TwigBridge in TwigBundle now extends this class and provides only
the additional methods for the FrameworkBundle interface.
Commits
-------
dd4d46a add limit to logger explosion
Discussion
----------
add limit to logger explosion
This limit is required to display complete query with e.g. "array" type in it.
ping @willdurand
Commits
-------
9ef5e95 Add connection name in the propel data collector
Discussion
----------
Add connection name in the propel data collector
Bug fix: no
Feature addition: yes, This will allow to explain a propel query on a specific connection
Backwards compatibility break: no
Symfony2 tests pass: yes
- Require PR propelorm/Propel#315
- Related to PR propelorm/PropelBundle#129
cc @willdurand
---------------------------------------------------------------------------
by willdurand at 2012-03-16T18:17:26Z
@fabpot please, let me merge Propel related PRs before that one, thanks!
---------------------------------------------------------------------------
by willdurand at 2012-03-26T08:38:36Z
@fabpot good to go from my point of view
Commits
-------
10947cb [DoctrineBridge][Security] Fixes bug that prevents repository's refreshUser from being called
Discussion
----------
[Security][DoctrineBridge] Fixes bug that prevents repository's refreshUser from being called
---------------------------------------------------------------------------
by marcw at 2012-02-21T08:46:09Z
Updated. What do you guys think about this patch ?
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-21T08:57:47Z
Isnt this a bit dangerous, the custom repository implementing refreshUser should always be called first right? You wouldnt specify the $property property if your class has custom implementations would you?
---------------------------------------------------------------------------
by marcw at 2012-02-21T09:05:08Z
@henrikbjorn At this time, the refreshUser method is never called from the custom repository, even if you don't specify the "property" property. This patch fixes this.
---------------------------------------------------------------------------
by marcw at 2012-02-21T09:44:06Z
Updated & Squashed.
---------------------------------------------------------------------------
by stof at 2012-02-21T10:03:33Z
@marcw please move the retrieval of the id in the ``else`` block, like in my comment as it is useless to do this logic for the case where the userProviderInterface is implemented (and it will answer to @vicb by making it impossible to write it with elseif)
---------------------------------------------------------------------------
by marcw at 2012-02-21T10:19:06Z
I'm not sure about this, but Isn't the check of the id essential here to ensure that the entity is a persisted one ?
---------------------------------------------------------------------------
by stof at 2012-02-21T10:21:55Z
@marcw if the interface is used, it means that the user wants to do the work himself. So you should really let him do the way he wants. If he does not use the id to refresh the user, he could choose not to include it in the serialized data.
Retrieving the id is needed for the ``find()`` call because we pass the id as argument and so we fail when the serialized data don't contain it
---------------------------------------------------------------------------
by marcw at 2012-02-21T10:33:30Z
@stof Roger that. I'll do the fix.
---------------------------------------------------------------------------
by marcw at 2012-02-21T10:41:58Z
Updated & Squashed, again.
---------------------------------------------------------------------------
by stof at 2012-02-21T11:00:44Z
btw, to answer to your previous question, the exception when retrieving the id does not check if the object is persisted (you need to reach teh DB for this, which is what find() does) but that the id is part of the serialized data to give a better error reporting.
---------------------------------------------------------------------------
by fabpot at 2012-03-07T19:39:33Z
ready to be merged now?
---------------------------------------------------------------------------
by henrikbjorn at 2012-03-08T07:21:37Z
would say so.
---------------------------------------------------------------------------
by dlsniper at 2012-03-25T11:58:34Z
Hi, can this be merged now or not?
Commits
-------
0c83c5d [Form] Alternate syntax for form_theme
Discussion
----------
[RFC][Form] Alternate syntax for form_theme
before
`{% form_theme form _self "::base.html.twig" %}`
after
`{% form_theme form with "::base.html.twig" %}`
`{% form_theme form with varTheme %}`
`{% form_theme form with [_self, "::base.html.twig"] %}`
_the former syntax is still supported_
---------------------------------------------------------------------------
by stof at 2012-03-12T15:42:32Z
do you really need ``with`` ?
---------------------------------------------------------------------------
by vicb at 2012-03-12T15:50:41Z
it's not needed but I find it more clear (It can be drop if a consensus is reached)
---------------------------------------------------------------------------
by fabpot at 2012-03-12T17:05:46Z
+1 for `with`. Documentation for master should be updated as well.
---------------------------------------------------------------------------
by Tobion at 2012-03-13T02:26:22Z
+1 for `with`, but the syntax without array like `{% form_theme form with "::base.html.twig" %}` should also be supported
---------------------------------------------------------------------------
by vicb at 2012-03-13T07:16:55Z
`[]` are nice as they clearly indicate the ability to use multiple themes (which I think is yet to be documented). We'll pick the most popular syntax only.
---------------------------------------------------------------------------
by stof at 2012-03-13T08:16:40Z
@vicb supporting a string instead of an array should be possible when you need only one element. supporting several ones and turning it into an array is the mistake we made for 2.0
---------------------------------------------------------------------------
by hhamon at 2012-03-13T08:16:45Z
+1 for the new syntax
---------------------------------------------------------------------------
by vicb at 2012-03-13T08:29:45Z
@stof @Tobion what about using the former syntax then ?
---------------------------------------------------------------------------
by Baachi at 2012-03-13T08:32:09Z
+1 for new syntax. But it should be possible to use strings instead of arrays.
---------------------------------------------------------------------------
by stof at 2012-03-13T08:33:07Z
@vicb Having one wyntax using ``with`` and the other without will confuse users IMO. this is why I suggested allowing to pass a Twig array without adding an extra word
---------------------------------------------------------------------------
by stof at 2012-03-13T08:40:02Z
@Baachi not stringS as it is precisely what we are trying to solve :)
---------------------------------------------------------------------------
by Baachi at 2012-03-13T08:42:03Z
Oh sry. I mean __string__. :)
---------------------------------------------------------------------------
by fabpot at 2012-03-13T11:16:30Z
+1 for supporting a string or an array with the new syntax as using only one element is probably the most common use case. But then, why not supporting any valid Twig expression?
---------------------------------------------------------------------------
by vicb at 2012-03-13T11:54:51Z
Something like the latest commit ? (Tests have to be updated).
@fabpot What is the best place to handle array / non-array ? This is currenlty handled in the node but the parser might be a better place.
---------------------------------------------------------------------------
by fabpot at 2012-03-13T13:23:08Z
@vicb: I would just remove the special array case in the node as it's not needed anymore.
---------------------------------------------------------------------------
by fabpot at 2012-03-13T13:24:15Z
... and update FormExtension::setTheme() to also accept a string in which case we convert it to an array there.
---------------------------------------------------------------------------
by schmittjoh at 2012-03-13T14:26:17Z
I'd prefer a named argument instead of an ubiquitous "with" keyword which does not really tell me what's coming next.
Something like ``{% form_theme _form templates=[a, b, c] %}``. This is pretty nicely done for the assetic tags "javascripts", and "stylesheets".
---------------------------------------------------------------------------
by Tobion at 2012-03-13T16:04:26Z
@schmittjoh it would only make sense if there are multiple named arguments. With only one available it seems redundant.
Also `{% form_theme _form templates="template.html.twig" %}` is bad.
---------------------------------------------------------------------------
by vicb at 2012-03-14T07:59:08Z
I tend to agree with @Tobion but I'll have a closer look at assetic to see if we can make things more consistent.
---------------------------------------------------------------------------
by Seldaek at 2012-03-14T10:36:15Z
This would be more consistent with assetic, but assetic isn't really consistent with anything else in twig, although I see the benefits in that particular case for swapping and omitting parameters.
---------------------------------------------------------------------------
by schmittjoh at 2012-03-14T15:49:37Z
My goal was not really consistency, but I simply find it more obvious,
self-explanatory and easier to understand if you name things explicitly. We
are using the "with" keyword in several places and each time something
different is expected.
To me explicit naming is superior, but just my 2c
On Wed, Mar 14, 2012 at 4:36 AM, Jordi Boggiano <
reply@reply.github.com
> wrote:
> This would be more consistent with assetic, but assetic isn't really
> consistent with anything else in twig, although I see the benefits in that
> particular case for swapping and omitting parameters.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/3576#issuecomment-4495732
>
---------------------------------------------------------------------------
by Tobion at 2012-03-14T16:48:01Z
When I first saw this tag I didn't understand the role of first parameter.
So if we use johannes suggestion it should rather be `{% form_theme form=myForm templates=[a, b, c] %}`
---------------------------------------------------------------------------
by mvrhov at 2012-03-14T18:09:09Z
Before we complicate this any further can I add another thing here.
Moving to dedicated issue: Inflexible form theming #3598
---------------------------------------------------------------------------
by vicb at 2012-03-14T18:20:54Z
@mvrhov that is not the good place to discuss this (both this particular issue and GH as this is a support request).
_Have you tried `{% form_theme form.subForm ... %}`_
---------------------------------------------------------------------------
by vicb at 2012-03-15T07:39:14Z
Where do you think we should go:
1. `{% form_theme form with [_self, "::base.html.twig"] %}`
2. `{% form_theme form=form src=[_self, "::base.html.twig"] %}`
Let's discuss the structure first & not the details (i.e. src vs templates).
---------------------------------------------------------------------------
by Baachi at 2012-03-15T07:52:51Z
I tend to ```{% form_theme form with [_self, "::base.html.twig"] %}```, because its more consistent to the twig syntax.
---------------------------------------------------------------------------
by fabpot at 2012-03-15T13:10:56Z
@vicb: I like 1) more than 2) as this how the built-in tags work.
To keep BC even further, can we just remove the `with` keyword? To make it BC, we just need to have a look at extra parameters and add it to an array if they exist.
---------------------------------------------------------------------------
by Tobion at 2012-03-15T13:19:52Z
For newcomers 2) is definitely easier to understand. But it would also only make sense if you can change the parameter order, so `{% form_theme form=form src=[_self, "::base.html.twig"] %}` == ` {% form_theme src=[_self, "::base.html.twig"] form=form %}`. At the same time it reduces consistency. So for experienced developers option 1) [without "with"] is less redundant and preferable.
---------------------------------------------------------------------------
by vicb at 2012-03-15T13:53:49Z
@fabpot removing the `with` will make `Parser::parsePostfixException()` scream when providing an array of themes.
Commits
-------
265360d [DoctrineBridge] Simpler result checking in UniqueEntityValidator
Discussion
----------
[DoctrineBridge] Simpler result checking in UniqueEntityValidator
In 928e352d09, support for MongoDB cursors was implemented by converting an Iterable, non-ArrayAccess object to an array. The ArrayAccess check didn't seem purposeful, since cursors are only Iterable and ORM returns real arrays. Since we only need to access the first element of the cursor (and only in cases where the count is exactly 1), we can simply use current() to handle Iterables and arrays.
@henrikbjorn: Any thoughts on this? I was testing @stof's work in doctrine/DoctrineMongoDBBundle#68 and our Symfony submodule was a bit old, so I fixed UniqueEntityValidator on my local machine before I realized you had come up with a solution a few weeks ago.
Commits
-------
71493a2 [DoctrineBridge] Compiler pass for registering event listeners/subscribers
f15dde6 [DoctrineBridge] ContainerAwareEventManager class
Discussion
----------
[DoctrineBridge] ContainerAwareEventManager class
```
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
[](http://travis-ci.org/jmikola/symfony)
This allows services to be registered (and lazily loaded) with Doctrine Common's EventManager.
It is ported from @schmittjoh's previous commits here: doctrine/DoctrineBundle#23. I'd like to integrate this with DoctrineMongoDBBundle, so the Bridge once again seemed like an ideal alternative to duplicating code.
---------------------------------------------------------------------------
by jmikola at 2012-02-23T20:37:51Z
Per conversation with @stof in doctrine/DoctrineBundle#23, I'm also going to integrate the compiler pass (an abstract version both bundles can use) into this PR.
---------------------------------------------------------------------------
by jmikola at 2012-02-23T21:56:47Z
Just realized there's an issue with the naming assumptions, since Doctrine ORM uses "doctrine" as its registry service ID but "doctrine.dbal" as its event manager prefix. Fixing.
Commits
-------
9c8a283 Some \SessionHandlerInterface related documentation updates
9b2de81 Fixed \SessionHandlerInterface in DbalSessionStorage
Discussion
----------
Some \SessionHandlerInterface related updates
---------------------------------------------------------------------------
by snc at 2012-02-23T20:01:51Z
I checked the `Locale` stub in the documentation and it looks like the `\` is not prefixed, so I'll change this, too.
---------------------------------------------------------------------------
by drak at 2012-02-24T07:40:39Z
We really need some tests for the bridge classes, even if they stubs which cause the compiler to at least parse the class, would pick up refactorings like this.
In 928e352d09, support for MongoDB cursors was implemented by converting an Iterable, non-ArrayAccess object to an array. The ArrayAccess check didn't seem purposeful, since cursors are only Iterable and ORM returns real arrays. Since we only need to access the first element of the cursor (and only in cases where the count is exactly 1), we can simply use current() to handle Iterables and arrays.
This was imported from DoctrineBundle (see: doctrine/DoctrineBundle#23), since it can be used by other Doctrine bundles, too. It utilizes the ContainerAwareEventManager from f15dde6c59.
Commits
-------
c754f28 [DoctrineBridge] Rename data fixtures loader class
af84805 [DoctrineBridge] Suggest doctrine/data-fixtures dependency
e4243a1 [DoctrineBridge] Add common data fixtures loader
Discussion
----------
[DoctrineBridge] Add common data fixtures loader
Symfony does not depend on doctrine/data-fixtures, but having this class in the bridge would enable DoctrineMongoDBBundle (and possibly others) to load fixtures without requiring DoctrineFixturesBundle to be installed.
Additionally, DoctrineFixturesBundle seems to only consist of this class and a command for loading ORM fixtures. With this in the bridge, we can possibly eliminate DoctrineFixturesBundle altogether by merging its command into DoctrineBundle.
---------------------------------------------------------------------------
by stof at 2012-02-11T19:40:17Z
The reason to have a separate bundle for the ORM fixtures was that the ORM is released whereas the DataFixtures library is still in alpha versions. So we wanted to avoid having it in Symfony itself for the 2.0 release. It could maybe change now that we have the bundle in a separate repo.
The other solution could be to put all commands related to fixtures in DoctrineFixturesBundle but IIRC @beberlei rejected a PR trying to make the same command work for ORM and PHPCR.
@beberlei what do you think about these suggestions ? And what is missing in DataFixtures to release it ? It has not changed recently except for the addition of the typehint and an update of the PHPCR purger
---------------------------------------------------------------------------
by fabpot at 2012-02-14T23:30:23Z
The Symfony bridges provide integration between a third-party library and Symfony components. IIUC, this PR is only about Doctrine and as such it is not in the scope of the bridge. It should be done "somewhere" in the Doctrine namespace (what about common for instance?).
---------------------------------------------------------------------------
by stof at 2012-02-14T23:34:19Z
@fabpot no it is not a Doctrine-only code. This extended loader is about integrating the Doctrine DataFixtures library with the DI component to allow fixtures to be container-aware (it does absolutely nothing else fancy btw). So this *is* in the scope of the bridge.
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:40:12Z
I second @stof's point here. This class is specifically for loading fixtures into application with a service container. Likewise, that is why the base class it inherits is in the common data-fixtures library.
Since this is common to both ORM and ODM, the most logical home for it would be DoctrineCommonBundle, and I believe that's what the bridge is :)
---------------------------------------------------------------------------
by stof at 2012-02-15T01:53:17Z
@jmikola not even a DoctrimeCommonBundle IMO. This is not about integrating things with the fullstack framework but with one component
Commits
-------
88b826d [Propel] Fixed typo, removed useless use statement, used getData() instead of casting a PropelCollection
46d28cd [Propel] Fixed the CollectionToArray transformer
1f20fb1 [Propel] Removed useless code
3910735 [Propel] Avoid to duplicate objects
d69144c [Propel] Refactored the CollectionToArray transformer
1706671 [Propel] Fixed naming to reflect Doctrine bridge
1f277df [Propel] Removed useless ModelToIdTransformer
Discussion
----------
Cleaned the propel bridge (+ fixes)
I've fixed the `ModelChoiceList` with `multiple=true`, and I removed useless code.
This PR will ensure everything works fine, but it requires the following fix for Propel: https://github.com/propelorm/Propel/pull/286.
---------------------------------------------------------------------------
by willdurand at 2012-02-11T20:04:10Z
@cedriclombardot this PR will fix your issues with Sf2 + Propel in your admingen
@bschussek nevermind my comments on Twitter, it seems ok now
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: -
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
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: -
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
-------
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)
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
-------
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
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
-------
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
* 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.
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
-------
20f96bd Fix CS
2f47cca [Propel1] Add a PropelExtension
Discussion
----------
[Propel1] Add a PropelExtension
The propel extension allow to use propel specific type (ModelType) outside of
Symfony2.
---------------------------------------------------------------------------
by rouffj at 2012/01/01 15:36:10 -0800
@Stof Fixed :).
---------------------------------------------------------------------------
by willdurand at 2012/01/02 07:38:22 -0800
👍
