* 2.6:
Configure firewall's kernel exception listener with configured entry point or a default entry point
PSR-2 fixes
[DependencyInjection] make paths relative to __DIR__ in the generated container
[FrameworkBundle][Router Cmd] use debug namespace.
[FrameworkBundle] Update deprecated service call
Removed a dev annotation from a version constraint
Fixed the syntax of a composer.json file
Fixed the symfony/config version constraint
Tweaked the password-compat version constraint
Docblock fixes
[Filesystem] fix lock file permissions
Remove dialog usage
define constant only if it wasn't defined before
Fix incorrect spanish translation
Fixed typos
Fixed a docblock
bumped Symfony version to 2.6.1
updated VERSION for 2.6.0
updated CHANGELOG for 2.6.0
removed unneeded check
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
* 2.5:
Configure firewall's kernel exception listener with configured entry point or a default entry point
PSR-2 fixes
[DependencyInjection] make paths relative to __DIR__ in the generated container
Fixed the syntax of a composer.json file
Fixed the symfony/config version constraint
Tweaked the password-compat version constraint
Docblock fixes
Remove dialog usage
define constant only if it wasn't defined before
Fix incorrect spanish translation
Fixed typos
Conflicts:
src/Symfony/Bundle/TwigBundle/Controller/ExceptionController.php
src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php
src/Symfony/Component/OptionsResolver/Options.php
src/Symfony/Component/OptionsResolver/OptionsResolverInterface.php
src/Symfony/Component/Process/ProcessPipes.php
src/Symfony/Component/Security/Http/Tests/Firewall/RememberMeListenerTest.php
src/Symfony/Component/Serializer/Normalizer/DenormalizableInterface.php
src/Symfony/Component/Validator/ConstraintViolation.php
src/Symfony/Component/Yaml/Inline.php
src/Symfony/Component/Yaml/Parser.php
* 2.3:
Configure firewall's kernel exception listener with configured entry point or a default entry point
PSR-2 fixes
[DependencyInjection] make paths relative to __DIR__ in the generated container
Fixed the syntax of a composer.json file
Fixed the symfony/config version constraint
Tweaked the password-compat version constraint
Docblock fixes
define constant only if it wasn't defined before
Fix incorrect spanish translation
Fixed typos
Conflicts:
composer.json
src/Symfony/Bridge/Twig/TwigEngine.php
src/Symfony/Bundle/FrameworkBundle/Controller/Controller.php
src/Symfony/Bundle/FrameworkBundle/Templating/Loader/FilesystemLoader.php
src/Symfony/Bundle/FrameworkBundle/composer.json
src/Symfony/Component/Console/Descriptor/MarkdownDescriptor.php
src/Symfony/Component/Console/Helper/TableHelper.php
src/Symfony/Component/Console/Tests/Helper/HelperSetTest.php
src/Symfony/Component/Debug/ErrorHandler.php
src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php
src/Symfony/Component/Finder/Tests/Iterator/RecursiveDirectoryIteratorTest.php
src/Symfony/Component/Form/Tests/Extension/Core/DataMapper/PropertyPathMapperTest.php
src/Symfony/Component/HttpFoundation/Response.php
src/Symfony/Component/HttpFoundation/StreamedResponse.php
src/Symfony/Component/HttpKernel/Controller/ControllerResolver.php
src/Symfony/Component/HttpKernel/Controller/ControllerResolverInterface.php
src/Symfony/Component/HttpKernel/Debug/TraceableEventDispatcher.php
src/Symfony/Component/HttpKernel/Fragment/RoutableFragmentRenderer.php
src/Symfony/Component/HttpKernel/Tests/DataCollector/RequestDataCollectorTest.php
src/Symfony/Component/Intl/NumberFormatter/NumberFormatter.php
src/Symfony/Component/Process/Process.php
src/Symfony/Component/Process/Tests/AbstractProcessTest.php
src/Symfony/Component/PropertyAccess/PropertyAccessorBuilder.php
src/Symfony/Component/Routing/Tests/Fixtures/validpattern.php
src/Symfony/Component/Security/Http/RememberMe/TokenBasedRememberMeServices.php
src/Symfony/Component/Security/composer.json
src/Symfony/Component/Serializer/Encoder/XmlEncoder.php
src/Symfony/Component/Serializer/Normalizer/GetSetMethodNormalizer.php
src/Symfony/Component/Stopwatch/StopwatchEvent.php
src/Symfony/Component/Stopwatch/StopwatchPeriod.php
src/Symfony/Component/Templating/PhpEngine.php
src/Symfony/Component/Templating/TemplateReference.php
src/Symfony/Component/Templating/TemplateReferenceInterface.php
src/Symfony/Component/Translation/TranslatorInterface.php
src/Symfony/Component/Validator/ConstraintViolation.php
src/Symfony/Component/Validator/ExecutionContextInterface.php
src/Symfony/Component/Validator/Mapping/ClassMetadata.php
src/Symfony/Component/Validator/MetadataFactoryInterface.php
The service `security.context` is now deprecated due to PR #11690.
This commit updates PR #11593 replacing `security.context` with
`security.authorization_checker` in the `isGranted()` controller
shortcut.
We are always using $this->container->get() and now we're using the short-cut sometimes to access to a service.
It could be nice to stay with $this->container->get(), so for those who copy and paste the Controller to create a ControllerUtils, they wont have to change it (in fact neither ControllerUtils::get() nor ControllerUtils::has() exists).
See: http://www.whitewashing.de/2013/06/27/extending_symfony2__controller_utilities.html
* 2.4:
unified return null usages
[Validator] added Japanese translation
Textarea value should default to empty string instead of null.
Fix doc blocks
[Process] Fix#10681, process are failing on Windows Server 2003
updated doc
[Security] fix DBAL connection typehint
[HttpFoundation] status 201 is allowed to have a body
unified return null usages
Conflicts:
src/Symfony/Component/DependencyInjection/ContainerBuilder.php
src/Symfony/Component/DomCrawler/Crawler.php
src/Symfony/Component/Security/Core/Authentication/Provider/PreAuthenticatedAuthenticationProvider.php
* 2.3:
Textarea value should default to empty string instead of null.
Fix doc blocks
[Process] Fix#10681, process are failing on Windows Server 2003
[Security] fix DBAL connection typehint
[HttpFoundation] status 201 is allowed to have a body
unified return null usages
Conflicts:
src/Symfony/Component/Console/Helper/DescriptorHelper.php
src/Symfony/Component/DependencyInjection/ContainerBuilder.php
src/Symfony/Component/Finder/Tests/Iterator/RecursiveDirectoryIteratorTest.php
src/Symfony/Component/Form/Extension/Core/DataTransformer/IntegerToLocalizedStringTransformer.php
src/Symfony/Component/HttpKernel/Fragment/InlineFragmentRenderer.php
This PR was merged into the 2.3 branch.
Discussion
----------
unified return null usages
| Q | A
| ------------- | ---
| License | MIT
This PR unifies the way we return `null` from a function or method:
* always use `return;` instead of `return null;` (the current code base uses both);
* never use `return;` at the end of a function/method.
Commits
-------
d1d569b unified return null usages
* 2.4:
made types consistent with those defined in Hack
made {@inheritdoc} annotations consistent across the board
made {@inheritdoc} annotations consistent across the board
fixed types in phpdocs
[Debug] Fixed ClassNotFoundFatalErrorHandler on windows.
made phpdoc types consistent with those defined in Hack
Add support Thai translations
[Validator] Add missing czech translations
made types consistent with those defined in Hack
removed extra/unsupported arguments
[HttpKernel] fixed an error message
[TwigBundle] removed undefined argument
[Translation] Make IcuDatFileLoader/IcuResFileLoader::load invalid resource compatible with HHVM.
Conflicts:
src/Symfony/Component/Console/Helper/TableHelper.php
src/Symfony/Component/DependencyInjection/Loader/XmlFileLoader.php
src/Symfony/Component/Form/FormError.php
src/Symfony/Component/HttpKernel/Debug/TraceableEventDispatcher.php
src/Symfony/Component/Process/ProcessPipes.php
src/Symfony/Component/PropertyAccess/PropertyAccessor.php
src/Symfony/Component/Security/Acl/Dbal/MutableAclProvider.php
src/Symfony/Component/Security/Http/RememberMe/TokenBasedRememberMeServices.php
src/Symfony/Component/Translation/Dumper/FileDumper.php
src/Symfony/Component/Validator/ConstraintViolation.php
src/Symfony/Component/Validator/Constraints/EmailValidator.php
src/Symfony/Component/Validator/ExecutionContextInterface.php
src/Symfony/Component/Validator/Mapping/BlackholeMetadataFactory.php
* 2.3:
made {@inheritdoc} annotations consistent across the board
fixed types in phpdocs
made phpdoc types consistent with those defined in Hack
Add support Thai translations
made types consistent with those defined in Hack
removed extra/unsupported arguments
[HttpKernel] fixed an error message
[TwigBundle] removed undefined argument
[Translation] Make IcuDatFileLoader/IcuResFileLoader::load invalid resource compatible with HHVM.
Conflicts:
src/Symfony/Bridge/ProxyManager/Tests/LazyProxy/Fixtures/php/lazy_service.php
src/Symfony/Bundle/FrameworkBundle/Command/ContainerDebugCommand.php
src/Symfony/Bundle/FrameworkBundle/Templating/Loader/FilesystemLoader.php
src/Symfony/Bundle/WebProfilerBundle/EventListener/WebDebugToolbarListener.php
src/Symfony/Component/Config/Definition/ReferenceDumper.php
src/Symfony/Component/Console/Helper/DescriptorHelper.php
src/Symfony/Component/Debug/ErrorHandler.php
src/Symfony/Component/Finder/Tests/Iterator/RecursiveDirectoryIteratorTest.php
src/Symfony/Component/Form/Extension/Core/DataTransformer/IntegerToLocalizedStringTransformer.php
src/Symfony/Component/Form/Tests/Extension/Core/DataMapper/PropertyPathMapperTest.php
src/Symfony/Component/HttpFoundation/Response.php
src/Symfony/Component/HttpFoundation/StreamedResponse.php
src/Symfony/Component/HttpKernel/Debug/TraceableEventDispatcher.php
src/Symfony/Component/HttpKernel/EventListener/ProfilerListener.php
src/Symfony/Component/HttpKernel/Fragment/FragmentHandler.php
src/Symfony/Component/HttpKernel/Fragment/RoutableFragmentRenderer.php
src/Symfony/Component/HttpKernel/Kernel.php
src/Symfony/Component/HttpKernel/Tests/Fixtures/KernelForTest.php
src/Symfony/Component/Intl/NumberFormatter/NumberFormatter.php
src/Symfony/Component/Security/Core/Authorization/AccessDecisionManager.php
src/Symfony/Component/Stopwatch/StopwatchPeriod.php
src/Symfony/Component/Translation/TranslatorInterface.php
src/Symfony/Component/Validator/ConstraintValidatorFactory.php
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.
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.
This adds to convience methods, for two separate reasons:
* Controller::getDoctrine() - this will allow method completion on the Registry class to work in IDEs, is slightly shorter, and should feel very "concrete" to beginners
* Registry::getRepository() - the repository is a very convenient thing to need - this allows it to be fetched much more succintly
Overall Before:
$product = $this->get('doctrine')
->getEntityManager()
->getRepository('AcmeDemoBundle:Product')
->find($id);
Overall After (with IDE method auto-completion for `getRepository`):
$product = $this->getDoctrine()
->getRepository('AcmeDemoBundle:Product')
->find($id);
The rationale is that this is a very common task and we can't expect non-advanced users to have to remember what the fully-qualified
class name of the Exception is in order to use it.
Some question whether or not the base Controller should be included at all. I think it absolutely must be included because it's important for beginners and for rapid development of smaller features/applications (and rapid development is good for beginners).
So, assuming that we *do* like the base Controller, we should really use it to its fullest potential - making the lives of developers as easy as possible.
The Response is not available in the DIC anymore.
When you need to create a response, create an instance of
Symfony\Component\HttpFoundation\Response instead.
As a side effect, the Controller::createResponse() and Controller::redirect()
methods have been removed and can easily be replaced as follows:
return $this->createResponse('content', 200, array('foo' => 'bar'));
return new Response('content', 200, array('foo' => 'bar'));
return $this->redirect($url);
return Response::createRedirect($url);
A Controller must now implements ControllerInterface.
The BaseController can be used as the base class for Controllers.
The Controller class adds some proxy methods and an array access to the Container.