|
1 | 1 | .. index:: |
2 | 2 | single: Config; Caching based on resources |
3 | 3 |
|
4 | | -Caching Based on Resources |
| 4 | +Caching based on Resources |
5 | 5 | ========================== |
6 | 6 |
|
7 | | -When all configuration resources are loaded, you may want to process the configuration |
8 | | -values and combine them all in one file. This file acts like a cache. Its |
9 | | -contents don’t have to be regenerated every time the application runs – only |
10 | | -when the configuration resources are modified. |
| 7 | +When all configuration resources are loaded, you may want to process the |
| 8 | +configuration values and combine them all in one file. This file acts |
| 9 | +like a cache. Its contents don’t have to be regenerated every time the |
| 10 | +application runs – only when the configuration resources are modified. |
11 | 11 |
|
12 | 12 | For example, the Symfony Routing component allows you to load all routes, |
13 | 13 | and then dump a URL matcher or a URL generator based on these routes. In |
14 | | -this case, when one of the resources is modified (and you are working in a |
15 | | -development environment), the generated file should be invalidated and regenerated. |
16 | | -This can be accomplished by making use of the :class:`Symfony\\Component\\Config\\ConfigCache` |
17 | | -class. |
18 | | - |
19 | | -The example below shows you how to collect resources, then generate some code |
20 | | -based on the resources that were loaded, and write this code to the cache. The |
21 | | -cache also receives the collection of resources that were used for generating |
22 | | -the code. By looking at the "last modified" timestamp of these resources, |
23 | | -the cache can tell if it is still fresh or that its contents should be regenerated:: |
| 14 | +this case, when one of the resources is modified (and you are working |
| 15 | +in a development environment), the generated file should be invalidated |
| 16 | +and regenerated. This can be accomplished by making use of the |
| 17 | +:class:`Symfony\\Component\\Config\\ConfigCache` class. |
| 18 | + |
| 19 | +The example below shows you how to collect resources, then generate some |
| 20 | +code based on the resources that were loaded and write this code to the |
| 21 | +cache. The cache also receives the collection of resources that were used |
| 22 | +for generating the code. By looking at the "last modified" timestamp of |
| 23 | +these resources, the cache can tell if it is still fresh or that its contents |
| 24 | +should be regenerated:: |
24 | 25 |
|
25 | 26 | use Symfony\Component\Config\ConfigCache; |
26 | 27 | use Symfony\Component\Config\Resource\FileResource; |
@@ -52,8 +53,8 @@ the cache can tell if it is still fresh or that its contents should be regenerat |
52 | 53 | // you may want to require the cached code: |
53 | 54 | require $cachePath; |
54 | 55 |
|
55 | | -In debug mode, a ``.meta`` file will be created in the same directory as the |
56 | | -cache file itself. This ``.meta`` file contains the serialized resources, |
57 | | -whose timestamps are used to determine if the cache is still fresh. When not |
58 | | -in debug mode, the cache is considered to be "fresh" as soon as it exists, |
| 56 | +In debug mode, a ``.meta`` file will be created in the same directory as |
| 57 | +the cache file itself. This ``.meta`` file contains the serialized resources, |
| 58 | +whose timestamps are used to determine if the cache is still fresh. When |
| 59 | +not in debug mode, the cache is considered to be "fresh" as soon as it exists, |
59 | 60 | and therefore no ``.meta`` file will be generated. |
0 commit comments