|
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