@@ -895,28 +895,28 @@ matter), Symfony2 uses the standard ``render`` helper to configure ESI tags:
895
895
896
896
<?php echo $view['actions']->render(
897
897
new ControllerReference('...:news', array('max' => 5)),
898
- array('strategy ' => 'esi'))
898
+ array('renderer ' => 'esi'))
899
899
?>
900
900
901
901
<?php echo $view['actions']->render(
902
902
$view['router']->generate('latest_news', array('max' => 5), true),
903
- array('strategy ' => 'esi')
903
+ array('renderer ' => 'esi')
904
904
) ?>
905
905
906
- By using the ``esi `` rendering strategy (via the ``render_esi `` Twig
907
- function), you tell Symfony2 that the action should be rendered as an ESI tag.
908
- You might be wondering why you would want to use a helper instead of just
909
- writing the ESI tag yourself. That's because using a helper makes your
910
- application work even if there is no gateway cache installed.
911
-
912
- When using the default ``render `` function (or setting the strategy to
913
- ``default ``), Symfony2 merges the included page content into the main one
914
- before sending the response to the client. But if you use the ``esi `` strategy
915
- (i.e. call ``render_esi ``), *and * if Symfony2 detects that it's talking to
916
- a gateway cache that supports ESI, it generates an ESI include tag. But if
917
- there is no gateway cache or if it does not support ESI, Symfony2 will just
918
- merge the included page content within the main one as it would have done
919
- if you had used ``render ``.
906
+ By using the ``esi `` renderer (via the ``render_esi `` Twig function), you
907
+ tell Symfony2 that the action should be rendered as an ESI tag. You might be
908
+ wondering why you would want to use a helper instead of just writing the ESI
909
+ tag yourself. That's because using a helper makes your application work even
910
+ if there is no gateway cache installed.
911
+
912
+ When using the default ``render `` function (or setting the renderer to
913
+ ``inline ``), Symfony2 merges the included page content into the main one
914
+ before sending the response to the client. But if you use the ``esi `` renderer
915
+ (i.e. call ``render_esi ``), *and * if Symfony2 detects that it's talking to a
916
+ gateway cache that supports ESI, it generates an ESI include tag. But if there
917
+ is no gateway cache or if it does not support ESI, Symfony2 will just merge
918
+ the included page content within the main one as it would have done if you had
919
+ used ``render ``.
920
920
921
921
.. note ::
922
922
@@ -952,32 +952,31 @@ listener that must be enabled in your configuration:
952
952
# app/config/config.yml
953
953
framework :
954
954
# ...
955
- router_proxy : { path: /_proxy }
955
+ fragments : { path: /_fragment }
956
956
957
957
.. code-block :: xml
958
958
959
959
<!-- app/config/config.xml -->
960
960
<framework : config >
961
- <framework : router-proxy path =" /_proxy " />
961
+ <framework : fragments path =" /_fragment " />
962
962
</framework : config >
963
963
964
964
.. code-block :: php
965
965
966
966
// app/config/config.php
967
967
$container->loadFromExtension('framework', array(
968
968
// ...
969
- 'router_proxy ' => array('path' => '/_proxy '),
969
+ 'fragments ' => array('path' => '/_fragment '),
970
970
));
971
971
972
- One great advantage of this caching strategy is that you can make your
973
- application as dynamic as needed and at the same time, hit the application as
974
- little as possible.
972
+ One great advantage of the ESI renderer is that you can make your application
973
+ as dynamic as needed and at the same time, hit the application as little as
974
+ possible.
975
975
976
976
.. tip ::
977
977
978
- The proxy route doesn't point to a real controller. Instead, it's handled
979
- by an internal :class: `Symfony\\ Component\\ HttpKernel\\ EventListener\\ RouterProxyListener `
980
- class. This listener only responds to local IP addresses or trusted proxies.
978
+ The listener listener only responds to local IP addresses or trusted
979
+ proxies.
981
980
982
981
.. note ::
983
982
0 commit comments