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
-------
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
-------
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.
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
-------
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.
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
-------
10ecaba slovenian validators.xlf updated
Discussion
----------
Validators.sl.xlf updated
PR sent intentionally to symfony:master because of different translations set in translations.XYZ.xlf and translations.XYZ.xliff in current 2.0 branch.
Commits
-------
1cd74ec Added norwegian translations of validators
Discussion
----------
Added norwegian translations of validators
---------------------------------------------------------------------------
by stof at 2011/12/29 10:14:43 -0800
Can you send a PR to the 2.0 branch instead of master to add these translation for the ids 1 to 41 (missing in your PR btw) ? and then another PR to master for the ids 42 to 48 which are new for 2.1 ?
---------------------------------------------------------------------------
by antonbabenko at 2011/12/29 10:59:39 -0800
Ok, will do, but where can I find the correct original one ? I took german file as the most complete. Some languages have different amount of phrases and sources.
---------------------------------------------------------------------------
by javiereguiluz at 2011/12/29 11:23:04 -0800
@antonbabenko you can use the Spanish translation as an example (it was updated very recently and I initially made the same mistake ;) ):
* #2968 for 2.0 branch (added id 41)
* #2969 for master branch (added ids 42 - 48)
---------------------------------------------------------------------------
by antonbabenko at 2011/12/29 11:28:03 -0800
Thanks Javier.
Commits
-------
7c8bd3d [FrameworkBundle] Invalid composer ref fix
Discussion
----------
[FrameworkBundle] Invalid composer ref fix
Changes the `composer.json` reference in the FrameworkBundle to use the `symfony/translation` package rather than the current `symfony/translator` (which doesn't exist).
Commits
-------
0ed3497 [FrameworkBundle][translations] Updated Catalan translation
Discussion
----------
[FrameworkBundle][translations] Updated Catalan translation
Added some translations
---------------------------------------------------------------------------
by stof at 2012/01/04 19:14:29 -0800
Can you send the trans-unit 41 to the 2.0 branch as it is already part of the 2.0 release (ids 42 and above are new for 2.1)
---------------------------------------------------------------------------
by franmomu at 2012/01/05 00:53:49 -0800
Of course, I didn't realize
Commits
-------
887c0e9 moved EngineInterface::stream() to a new StreamingEngineInterface to keep BC with 2.0
473741b added the possibility to change a StreamedResponse callback after its creation
8717d44 moved a test in the constructor
e44b8ba made some cosmetic changes
0038d1b [HttpFoundation] added support for streamed responses
Discussion
----------
[HttpFoundation] added support for streamed responses
To stream a Response, use the StreamedResponse class instead of the
standard Response class:
$response = new StreamedResponse(function () {
echo 'FOO';
});
$response = new StreamedResponse(function () {
echo 'FOO';
}, 200, array('Content-Type' => 'text/plain'));
As you can see, a StreamedResponse instance takes a PHP callback instead of
a string for the Response content. It's up to the developer to stream the
response content from the callback with standard PHP functions like echo.
You can also use flush() if needed.
From a controller, do something like this:
$twig = $this->get('templating');
return new StreamedResponse(function () use ($templating) {
$templating->stream('BlogBundle:Annot:streamed.html.twig');
}, 200, array('Content-Type' => 'text/html'));
If you are using the base controller, you can use the stream() method instead:
return $this->stream('BlogBundle:Annot:streamed.html.twig');
You can stream an existing file by using the PHP built-in readfile() function:
new StreamedResponse(function () use ($file) {
readfile($file);
}, 200, array('Content-Type' => 'image/png');
Read http://php.net/flush for more information about output buffering in PHP.
Note that you should do your best to move all expensive operations to
be "activated/evaluated/called" during template evaluation.
Templates
---------
If you are using Twig as a template engine, everything should work as
usual, even if are using template inheritance!
However, note that streaming is not supported for PHP templates. Support
is impossible by design (as the layout is rendered after the main content).
Exceptions
----------
Exceptions thrown during rendering will be rendered as usual except that
some content might have been rendered already.
Limitations
-----------
As the getContent() method always returns false for streamed Responses, some
event listeners won't work at all:
* Web debug toolbar is not available for such Responses (but the profiler works fine);
* ESI is not supported.
Also note that streamed responses cannot benefit from HTTP caching for obvious
reasons.
---------------------------------------------------------------------------
by Seldaek at 2011/12/21 06:34:13 -0800
Just an idea: what about exposing flush() to twig? Possibly in a way that it will not call it if the template is not streaming. That way you could always add a flush() after your </head> tag to make sure that goes out as fast as possible, but it wouldn't mess with non-streamed responses. Although it appears flush() doesn't affect output buffers, so I guess it doesn't need anything special.
When you say "ESI is not supported.", that means only the AppCache right? I don't see why this would affect Varnish, but then again as far as I know Varnish will buffer if ESI is used so the benefit of streaming there is non-existent.
---------------------------------------------------------------------------
by cordoval at 2011/12/21 08:04:21 -0800
wonder what the use case is for streaming a response, very interesting.
---------------------------------------------------------------------------
by johnkary at 2011/12/21 08:19:48 -0800
@cordoval Common use cases are present fairly well by this RailsCast video: http://railscasts.com/episodes/266-http-streaming
Essentially it allows faster fetching of web assets (JS, CSS, etc) located in the <head></head>, allowing those assets to be fetched as soon as possible before the remainder of the content body is computed and sent to the browser. The end goal is to improve page load speed.
There are other uses cases too like making large body content available quickly to the service consuming it. Think if you were monitoring a live feed of JSON data of newest Twitter comments.
---------------------------------------------------------------------------
by lsmith77 at 2011/12/21 08:54:35 -0800
How does this relate the limitations mentioned in:
http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/
Am I right to understand that due to how twig works we are not really streaming the content pieces when we call render(), but instead the entire template with its layout is rendered and only then will we flush? or does it mean that the render call will work its way to the top level layout template and form then on it can send the content until it hits another block, which it then first renders before it continues to send the data?
---------------------------------------------------------------------------
by stof at 2011/12/21 09:02:53 -0800
@lsmith77 this is why the ``stream`` method calls ``display`` in Twig instead of ``render``. ``display`` uses echo to print the output of the template line by line (and blocks are simply method calls in the middle). Look at your compiled templates to see it (the ``doDisplay`` method)
Rendering a template with Twig simply use an output buffer around the rendering.
---------------------------------------------------------------------------
by fabpot at 2011/12/21 09:24:33 -0800
@lsmith77: We don't have the Rails problem thanks to Twig as the order of execution is the right one by default (the layout is executed first); it means that we can have the flush feature without any change to how the core works. As @stof mentioned, we are using `display`, not `render`, so we are streaming your templates for byte one.
---------------------------------------------------------------------------
by fabpot at 2011/12/21 09:36:41 -0800
@Seldaek: yes, I meant ESI with the PHP reverse proxy.
---------------------------------------------------------------------------
by fabpot at 2011/12/21 09:37:34 -0800
@Seldaek: I have `flush()` support for Twig on my todo-list. As you mentioned, It should be trivial to implement.
---------------------------------------------------------------------------
by fzaninotto at 2011/12/21 09:48:18 -0800
How do streaming responses deal with assets that must be called in the head, but are declared in the body?
---------------------------------------------------------------------------
by fabpot at 2011/12/21 09:52:12 -0800
@fzaninotto: What do you mean?
With Twig, your layout is defined with blocks ("holes"). These blocks are overridden by child templates, but evaluated as they are encountered in the layout. So, everything works as expected.
As noted in the commit message, this does not work with PHP templates for the problems mentioned in the Rails post (as the order of execution is not the right one -- the child template is first evaluated and then the layout).
---------------------------------------------------------------------------
by fzaninotto at 2011/12/21 10:07:35 -0800
I was referring to using Assetic. Not sure if this compiles to Twig the same way as javascript and stylesheet blocks placed in the head - and therefore executed in the right way.
---------------------------------------------------------------------------
by fabpot at 2011/12/21 10:34:59 -0800
@Seldaek: I've just added a `flush` tag in Twig 1.5: 1d6dfad4f5
---------------------------------------------------------------------------
by catchamonkey at 2011/12/21 13:29:22 -0800
I'm really happy you've got this into the core, it's a great feature to have! Good work.
Commits
-------
aacb2de use the forward compat version in the Filesystem service
Discussion
----------
use the forward compat version in the Filesystem service
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: ![Build Status](https://secure.travis-ci.org/lsmith77/symfony.png?branch=forward_compat_filesystem)
Fixes the following tickets: -
by changing the service it should fix any type hints for the Filesystem class inside 2.1, but it shouldn't affect anyone still type hinting the old location in 2.0 since the new forward compat file extends the old file.
See
00c988bf0c (commitcomment-820879)
---------------------------------------------------------------------------
by tobiassjosten at 2011/12/26 18:41:45 -0800
👍
Commits
-------
4afc6ac Updated CHANGELOG-2.1
3d3239c Added Filesystem Component mention in composer.json
5775a0a Added composer.json
b26ae4a Added README
fbe9507 Added LICENSE
818a332 [Component] Moved Filesystem class to its own component
Discussion
----------
Filesystem component
Related to #2946
William
---------------------------------------------------------------------------
by stof at 2011/12/22 10:58:25 -0800
you need to add the new component in the ``replace`` section of the main composer.json, and you also need to add it as a dependency for FrameworkBundle as it defines a service using it.
---------------------------------------------------------------------------
by stof at 2011/12/22 10:59:34 -0800
and you need to update the changelog file
---------------------------------------------------------------------------
by willdurand at 2011/12/22 11:06:04 -0800
@stof thanks. Is it ok ?
---------------------------------------------------------------------------
by stof at 2011/12/22 11:13:31 -0800
mentioning the move only once in the changelog would probably be enough (and it is especially not needed in the FrameworkBundle section IMO) but otherwise it's fine
To stream a Response, use the StreamedResponse class instead of the
standard Response class:
$response = new StreamedResponse(function () {
echo 'FOO';
});
$response = new StreamedResponse(function () {
echo 'FOO';
}, 200, array('Content-Type' => 'text/plain'));
As you can see, a StreamedResponse instance takes a PHP callback instead of
a string for the Response content. It's up to the developer to stream the
response content from the callback with standard PHP functions like echo.
You can also use flush() if needed.
From a controller, do something like this:
$twig = $this->get('templating');
return new StreamedResponse(function () use ($templating) {
$templating->stream('BlogBundle:Annot:streamed.html.twig');
}, 200, array('Content-Type' => 'text/html'));
If you are using the base controller, you can use the stream() method instead:
return $this->stream('BlogBundle:Annot:streamed.html.twig');
You can stream an existing file by using the PHP built-in readfile() function:
new StreamedResponse(function () use ($file) {
readfile($file);
}, 200, array('Content-Type' => 'image/png');
Read http://php.net/flush for more information about output buffering in PHP.
Note that you should do your best to move all expensive operations to
be "activated/evaluated/called" during template evaluation.
Templates
---------
If you are using Twig as a template engine, everything should work as
usual, even if are using template inheritance!
However, note that streaming is not supported for PHP templates. Support
is impossible by design (as the layout is rendered after the main content).
Exceptions
----------
Exceptions thrown during rendering will be rendered as usual except that
some content might have been rendered already.
Limitations
-----------
As the getContent() method always returns false for streamed Responses, some
event listeners won't work at all:
* Web debug toolbar is not available for such Responses (but the profiler works fine);
* ESI is not supported.
Also note that streamed responses cannot benefit from HTTP caching for obvious
reasons.
Commits
-------
3ae976c fixed CS
84ad40d added cache clear hook
Discussion
----------
[Cache][2.1] Added cache clear hook
Allows bundles to hook into the `cache:clear` command by using the `kernel.cache_clearer` tag instead of using the `event_dispatcher` service.
See #1884
Bug fix: No
Feature addition: Yes
Backwards compatibility break: No
Symfony2 tests pass: Yes
Fixes the following tickets: #1884
References the following tickets: #1884
---------------------------------------------------------------------------
by dustin10 at 2011/12/16 11:03:54 -0800
Rebased to squash all commits into one.
---------------------------------------------------------------------------
by lsmith77 at 2011/12/17 05:27:29 -0800
@fabpot: we figured that priorities wouldn't be needed for cleaning .. haven't tested the PR, but conceptually it looks good to me and aside from the priority stuff its modeled after the cache warners.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 09:46:26 -0800
@fabpot Updated to pass cache dir to `clear` method.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 10:02:21 -0800
@stof and @fabpot Another thought I just had. Should the `$this->getContainer()->get('cache_clearer')->clear($realCacheDir);` call in the `CacheClearCommand` be done before the warming?
---------------------------------------------------------------------------
by stof at 2011/12/19 10:03:59 -0800
indeed. the clearing should be done before the warming.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 10:19:28 -0800
Squashed all commits into one. Let me know if there is anything else.
---------------------------------------------------------------------------
by dustin10 at 2011/12/19 10:31:50 -0800
Fixed extra lines.
* 2.0:
fixed functional tests so that the cache/logs are specific to one version of Symfony (to avoid weird side effects)
[FrameworkBundle] Prove client insulation and non-insulation works in session tests.
[FrameworkBundle] Add tests to prove functional testing works with simultaneous clients.
[FrameworkBundle] Small changes to test setup.
[DoctrineBundle] Fixed incorrectly shown params
[SwiftmailerBundle] fixed the send email command when the queue does not extends Swift_ConfigurableSpool
* 2.0:
[FrameworkBundle] Added functional tests.
[Form] Added missing use statements (closes#2880)
[Console] Improve input definition output for Boolean defaults
[SecurityBundle] Changed environment to something unique.
2879: missing space between catch and the brace
#2688: Entities are generated in wrong folder (doctrine:generate:entities Namespace)
[TwigBundle] Fix the exception message escaping
Commits
-------
cd24fb8 change explode's limit parameter based on known variable content
b3cc270 minor optimalisations for explode
Discussion
----------
[FrameworkBundle][CssSelector][HttpFoundation][HttpKernel] [Security][Validator] Minor optimizations for "explode" function
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
I added limit parameter in some places, where it may be usefull. I did not check the context of what values may have been exploded. So to not break anything, I added +1 to limit parameter.
If you find out that in some places limit (or limit+1) is not important or meaningless, write a comment please and I will fix it.
---------------------------------------------------------------------------
by fabpot at 2011/12/07 06:56:49 -0800
Adding +1 just to be sure to not break anything is clearly something we won't do. What is the benefit of doing that anyway?
---------------------------------------------------------------------------
by pulzarraider at 2011/12/07 13:50:24 -0800
The main idea of making this PR was to notify about some places that may run faster with just adding one parameter to explode function.
If in code is someting like: ```list($a, $b) = explode(':', $s);```
Function ```explode``` will create n-items (depends on ```$s```), but we need in code only the first two items. There is no reason to let ```explode``` create more items in memory that are NEVER used in our code. The limit parameter is there for these situations, so let's use it.
I know that it is microoptimization and may look unimportant, but we are writing a framework - so people expect that code will be as fast as possible without this kind of mistakes.
As I've noticed above, I know that +1 is not ideal solution, but the fastest without debugging the code. I expect that someone (with good knowledge of that code) will look at it and write in comments if variable may contain 1 comma (dot or someting on what is doing the explode) or maybe 2 in some situations or more.
Anyway, +1 will not break anything, because same items are created as it is now, but no unnecessary item is created.
---------------------------------------------------------------------------
by fabpot at 2011/12/07 23:14:59 -0800
I'm +1 for adding the number to avoid problems but I'm -1 on the optimization side of things as it won't optimize anything.
---------------------------------------------------------------------------
by helmer at 2011/12/08 12:46:49 -0800
*.. The main idea of making this PR was to notify about some places that **may** run faster ..*
I am also unsure the optimization is really an optimization, care to benchmark (with meaningful inputs)? As for the limit+1 thing, why would you want to +1 it? The number of ``list`` arguments should always reflect the ``limit`` parameter, no?
---------------------------------------------------------------------------
by pulzarraider at 2011/12/08 23:11:34 -0800
@helmer please try this simple benchmark:
```
<?php
header('Content-Type: text/plain; charset=UTF-8');
define('COUNT', 10000);
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc:dddddddddddddddddddddd:eeeeeeeeeeeeeeeeeeeeeeeee:fffffffffffffffffffffffffff';
$start = microtime(true);
for ($i = 0; $i < COUNT; $i++) {
list($a, $b) = explode(':', $source_string);
}
$end = microtime(true)-$start;
echo 'without limit: '.$end."\n";
$start = microtime(true);
for ($i = 0; $i < COUNT; $i++) {
list($a, $b) = explode(':', $source_string, 2);
}
$end = microtime(true)-$start;
echo 'with limit: '.$end."\n";
```
My results are:
```
without limit: 0.057228803634644
with limit: 0.028676986694336
```
That is 50% difference (with APC enabled). Of course the result depends on the length of source string and if it's too short, the difference may be none or very very small. That's why I said, that it **may** run faster and is just a micro optimization.
---------------------------------------------------------------------------
by pulzarraider at 2011/12/08 23:18:12 -0800
@helmer And why +1? It depends on a code:
```
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc';
list($a, $b) = explode(':', $source_string, 2);
var_dump($a, $b);
```
and
```
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc';
list($a, $b) = explode(':', $source_string, 3);
var_dump($a, $b);
```
gives different results. That's why the content of the variable must be known.
---------------------------------------------------------------------------
by helmer at 2011/12/09 00:08:28 -0800
@pulzarraider Thanks for the benchmark, seems like a gain enough. Although, we are more likely having a scenario of:
``explode(':', 'a🅱️c')`` vs ``explode(':', 'a🅱️c', 3)`` with a ``COUNT`` of 10, where the difference is not even in microseconds anymore :)
The limit addition alters the behaviour though, ie suddenly you can define a controller [logical name](http://symfony.com/doc/current/book/routing.html#controller-string-syntax) as ´´AcmeBlogBundle:Blog:show:something``, and things go downhill from there on.
All that aside, I'm +1 for setting the limit to the exact number of ``list`` parameters, but certainly not number+1, this is just too wtfy (as you said, this was a safety thing, but I reckon for this PR to be merged it needs to be +0).
---------------------------------------------------------------------------
by drak at 2011/12/09 08:28:58 -0800
Overall `list()` is ugly as it's not very explicit. Even though it would mean extra lines, it's better to `explode()` then explicitly assign variables:
```
$parts = explode(':', $foo);
$name = $parts[0];
$tel = $parts[1];
```
`list()` is one of those bad relics from the PHP past...
---------------------------------------------------------------------------
by fabpot at 2011/12/11 10:07:47 -0800
@drak: why is `list` not explicit? It is in fact as explicit as the more verbose syntax you propose.
---------------------------------------------------------------------------
by pulzarraider at 2011/12/11 13:08:50 -0800
@drak: I agree with @fabpot. In speech of benchmarks ```list``` is faster then using a helper variable.
@fabpot, @helmer I've changed explode's limit to be correct (without +1) and removed some changes from this PR, where I can't find out what the content of variable may be. Unit tests pass, so I think it's ready for merge.
Commits
-------
db2d773 [FrameworkBundle] Improve the TemplateLocator exception message
Discussion
----------
Template locator/exception message
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Improve the error message to include the error message from the File Locator which is more accurate : the File Locator might also look in some fallback folder(s) (i.e. `%kernel.root_dir%/Resources`)
Commits
-------
fabe818 [EventDispatcher] Add reference to the EventDispatcher on the Event
Discussion
----------
[EventDispatcher] Add reference to the EventDispatcher on the Event
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
I don't like registering event listeners unless they are really used, it seems wasteful. So I tend to register listeners for the response event in other listeners, only when they will be required. @stof has [brought to my attention](fb243ace83 (commitcomment-696467)) that this may cause issues in Silex or any other situation where event listeners are not lazy loaded, since it creates a circular reference in that case.
With this PR, avoiding the circular reference is possible, without bloating the response listener with unnecessary "do I need to do anything?" code.
---------------------------------------------------------------------------
by schmittjoh at 2011/11/06 05:28:39 -0800
Did you do any benchmarks? It's just a feeling, but registering a listener at runtime might be more expensive than just having it always executed.
Also, I find these dynamic listeners a bit of a code smell. They are not easily testable, and the control flow is harder to track. Besides, you do not take into account subrequests which might happen in between.
---------------------------------------------------------------------------
by Seldaek at 2011/11/06 09:34:27 -0800
I don't see why it would be slower, if it's a commonly fired event yes you blast away the `sorted` listener cache every time you add one, but most of the time those optional listeners are for the response, which is typically not sorted yet when you add the listener, so I don't think there is any overhead.
As for the code smell, of course it's a matter of preference, but I have the opposite view on control flow, I find it weird that listeners are registered when they are not used in the end, while doing it my way I think it's more clear what happens.
For sub-requests, I'm not sure what you mean. In this instance, and in most response listeners I have seen, the sub-requests are always ignored anyway by the listener.
---------------------------------------------------------------------------
by drak at 2011/11/10 06:07:45 -0800
I don't see how loading up the dispatcher with a bunch of callables can be expensive - it's just loading an array basically.
Wouldn't it be better to have a separate `DispatcherAwareEvent extends Event`
class DispatcherAwareEvent extends Event
{
protected $dispatcher;
public function setDispatcher(EventDispatcher $dispatcher)
{
$this->dispatcher = $dispatcher;
}
public function getDispatcher()
{
return $this->dispatcher;
}
This can then be used as a base class for what you need `MyEvent extends DispatcherAwareEvent`
$event = new MyEvent($dispatcher, $foo);
$dispatcher->dispatch($event);
---------------------------------------------------------------------------
by Seldaek at 2011/11/10 06:18:57 -0800
@drak: Every event is part the event dispatching system and therefore should be aware of the dispatcher imo. It's not like the ContainerAwareInterface which is gluing things that do not especially have to know about the DIC together.
If we do that, then we have to start arguing every time we need the dispatcher in a given event, because the original author did not think it was necessary, and then that will only make it into the next minor version, etc. Not fun at all.
---------------------------------------------------------------------------
by drak at 2011/11/10 06:36:26 -0800
By the way, the event dispatchers looks to be pretty well optimized given the fact that it only sorts listeners if they are called, and then only once.
---------------------------------------------------------------------------
by drak at 2011/11/10 12:33:28 -0800
It just seems weird. I mean, following on, why isn't the event name a compulsory parameter also? - again, you can say both ways, if you need it, make it part of your custom Event class, or since it's a required param to be able to dispatch an event in the first place, make it part of the base Event class. All I'm saying it it seems suspicious when it could be achieved a different way.
For example, you could inject the dispatcher into the listener itself and then the event handler could access the dispatcher if it needs:
class MyListener
{
public function __construct(EventDispatcher $eventDispatcher)
{
//...
}
public function someListener(Event $event)
{
//...
}
}
---------------------------------------------------------------------------
by stof at 2011/11/10 15:20:07 -0800
@drak The issue when injecting the dispatcher in the listener is described in the issue: circular dependency: you need to create the dispatcher before the listener (as it is injected in it) and when the listener is not lazy-loaded (in Silex for instance), you need to create it before the dispatcher.
---------------------------------------------------------------------------
by drak at 2011/11/10 21:15:45 -0800
Indeed, although it might not unreasonable to expect to create the dispatcher first... but anyway I'm convinced!
Injecting the dispatcher could lead to some __very interesting possibilities__ as standard. While we are at it though, we should have a getter and setter for `$name` in the `Event` class and `$event->setName($eventname)` in the `dispatch()` method. Allowing an event to know it's name is very useful. It allows a single listener to be registered for multiple names, and even makes the event object reusable. I don't know why $name was removed, it was in the Symfony 1 dispatcher and while the new dispatcher is brilliant from an OO point of view, missing the name as standard is a big shame.
+1 from me.
* 2.0:
[Form] fixed previous merge
[Form] simplified previous merge
Also identify FirePHP by the X-FirePHP-Version header
[TwigBundle] Extract output buffer cleaning to method
[TwigBundle] Do not clean output buffering below initial level
Fixed rendering of FileType (value is not a valid attribute for input[type=file])
Added tests for string fix in DateTimeToArrayTransformer (8351a11286).
Added check for array fields to be integers in reverseTransform method. This prevents checkdate from getting strings as arguments and throwing incorrect ErrorException when submitting form with malformed (string) data in, for example, Date field. #2609
[Translation] removed unneeded methods
[Translation] added detection for circular references when adding a fallback catalogue
[DomCrawler] trim URI in getURI
[Yaml][Tests] Fixed missing locale string for Windows platforms which caused test to fail
Commits
-------
d974a4a Merge pull request #4 from stealth35/test_mo_loader
cf05646 delete useless tests
19f9de9 [Translation] fix gettext tests
965f2bf Merge pull request #3 from stealth35/test_mo_loader
9c2a26d [Translation] add Mo loader tests
9af2342 [Translation] Added the gettext loaders
Discussion
----------
[Translation] Added the gettext loaders
This is the squashed version of the work done by @xaav in #634.
@stealth35 you said you will work on the dumpers. do you have some stuff on it ?
---------------------------------------------------------------------------
by drak at 2011/10/24 19:28:43 -0700
Is there any more progress with this?
---------------------------------------------------------------------------
by stealth35 at 2011/10/25 00:57:19 -0700
I work on the dumpers, but the Po loader is wrong, caus' the Po ressource can be multiline,
msgid ""
"Here is an example of how one might continue a very long string\n"
"for the common case the string represents multi-line output.\n"
http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
Anyway the Po format is an intermediate format to Mo file, (like .txt to .res file for ICU), IMO we can just support the real gettext format : Mo
---------------------------------------------------------------------------
by stealth35 at 2011/11/03 02:00:24 -0700
@stof The MO Dumper is ready (stealth35/symfony@f2d1d5b4de), should we keep the PO format ?
---------------------------------------------------------------------------
by fabpot at 2011/11/07 08:50:59 -0800
@stealth35: The PO is what people will use for their translations. They will then dump it to MO. So, we need both PO and MO loaders and dumpers.
---------------------------------------------------------------------------
by stealth35 at 2011/11/08 01:25:39 -0800
@fabpot, I'm ready for both dumpers, you can merge this, and I'll open a PR for the dumpers
---------------------------------------------------------------------------
by fabpot at 2011/11/08 22:37:47 -0800
I've just had a look at this PR code again and I see that the unit tests are pretty slim. Is it possible to add some tests for the mo loader?
---------------------------------------------------------------------------
by stealth35 at 2011/11/09 01:15:25 -0800
@fabpot test send to @stof ✌️
---------------------------------------------------------------------------
by stof at 2011/11/09 02:22:55 -0800
and merged in this branch
---------------------------------------------------------------------------
by fabpot at 2011/11/09 02:39:09 -0800
The tests do not pass for me:
There was 1 error:
1) Symfony\Tests\Component\Translation\Loader\MoFileLoaderTest::testLoadDoesNothingIfEmpty
InvalidArgumentException: MO stream content has an invalid format.
/Users/fabien/work/symfony/git/symfony/src/Symfony/Component/Translation/Loader/MoFileLoader.php:79
/Users/fabien/work/symfony/git/symfony/src/Symfony/Component/Translation/Loader/MoFileLoader.php:46
/Users/fabien/work/symfony/git/symfony/tests/Symfony/Tests/Component/Translation/Loader/MoFileLoaderTest.php:34
--
There was 1 failure:
1) Symfony\Tests\Component\Translation\Loader\PoFileLoaderTest::testLoad
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
- 'foo' => 'bar'
)
/Users/fabien/work/symfony/git/symfony/tests/Symfony/Tests/Component/Translation/Loader/PoFileLoaderTest.php:25
Commits
-------
78883f9 Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}``
Discussion
----------
Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}`
Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}``
Bug fix: yes
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2424
---------------------------------------------------------------------------
by stof at 2011/10/18 07:44:48 -0700
@docteurklein still the same issue. github says it conflicts. Are you sure you fetched the latest version ?
Thus it should be sent to 2.0 IMO as it is a bugfix
---------------------------------------------------------------------------
by docteurklein at 2011/10/18 07:51:21 -0700
@stof Yes, i'm pretty sure I followed the patches sending flow. (http://symfony.com/doc/2.0/contributing/code/patches.html
My tools are telling me it's ok.
I then merged it into master without any problem, which is up to date with upstream.
Sorry for the inconvenience.
I'll try to send it to 2.0 branch.
---------------------------------------------------------------------------
by docteurklein at 2011/10/18 07:53:52 -0700
@stof, what's wrong with https://github.com/docteurklein/symfony/commits/ticket_2424 ?
---------------------------------------------------------------------------
by stof at 2011/10/18 08:28:21 -0700
hmm, seems like github has an issue when determining if it conflicts or not. It's sad
---------------------------------------------------------------------------
by henrikbjorn at 2011/10/20 09:49:56 -0700
Dosent this already work ? as classes are namespaces the / should be a \ i think ?
Works for routes at least.
Commits
-------
96235a6 cs fix
46a69f1 define a WarmableInterface and only warm the cache if it implements warmable to allow replacing the core router. this fixes#2422. combining routers will only really work when #2450 is merged too.
Discussion
----------
define a WarmableInterface and only warm the cache if it implements warmable
define a WarmableInterface and only warm the cache if it implements warmable to allow replacing the core router. this fixes#2422. combining routers will only really work when #2450 is merged too.
Bug fix: yes
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes*
Fixes the following tickets: #2422
(*) tests:
success for
phpunit src/Symfony/Bundle/FrameworkBundle/Tests/
and
phpunit tests/Symfony/Tests/Component/Routing/
but when running all tests, i have to put gc_disable() into autoload to avoid segmentation fault and then get (after 3000 successful tests):
PHP Fatal error: Call to undefined method Symfony\Tests\Component\HttpKernel\Debug\StopwatchTest::assertCount() in /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony/tests/Symfony/Tests/Component/HttpKernel/Debug/StopwatchTest.php on line 84
---------------------------------------------------------------------------
by stof at 2011/10/22 08:46:31 -0700
@dbu assertCount is new in PHP 3.6. It seems like the test of the new 2.1 feature has been written using 3.6-RC.
---------------------------------------------------------------------------
by dbu at 2011/10/22 09:40:07 -0700
@stof: ah, thanks for the hint. i hope you mean php 3.4 and not 3.6? but i assume symfony 2.1 should be able to run on 3.3, right?
anyways, the tests run through if i disable the StopWatch, so i guess we can consider the tests succeeding.
---------------------------------------------------------------------------
by stof at 2011/10/22 09:41:28 -0700
this is a method of PHPUnit TestCase class. I was talking about the PHPUnit version
If a request listener returns a response before calling the profiler
listener, the request will not be added in the stack leading to an error
during the handling of the kernel.response event. The profiler listener
should ideally be run first.
Commits
-------
ae342c7 unified toolbar.css
a7e4e70 unified profiler.css
09fe09e unified and corrected exception_layout.css
3a1674b unified and corrected exception.css
Discussion
----------
Unified and corrected CSS markup
Unified (spaces, braces, quotes, indention) and corrected (missing semicolon) the CSS markup.
Did not change any semantic, only markup!
@fabpot: New pull based on symfony:2.0 and changed formatting style as agreed in #2405
Commits
-------
63d2ce2 [FrameworkBundle] Fixed the ckeck for the router class
Discussion
----------
[FrameworkBundle] Fixed the ckeck for the router class
The getRouteCollection method is now part of the RouterInterface so the
command should accept any implementation of the interface instead of just
the implementations extending the core one.
The getRouteCollection method is now part of the RouterInterface so the
command should accept any implementation of the interface instead of just
the implementations extending the core one.