Changeset 10946
- Timestamp:
- 08/19/08 14:02:45 (3 months ago)
- Files:
-
- doc/branches/1.0/book/05-Configuring-Symfony.txt (modified) (5 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
doc/branches/1.0/book/05-Configuring-Symfony.txt
r9917 r10946 308 308 309 309 * `generator.yml`: For modules generated according to a database table (scaffoldings and administrations), this file defines how the interface displays rows and fields, and which interactions are proposed to the user (filters, sorting, buttons, and so on). Chapter 14 will tell you more about it. 310 * `module.yml`: This file contains custom parameters specific to a module (equivalent to the `app. `yml, but at the module level) and action configuration. Chapter 6 provides more details.310 * `module.yml`: This file contains custom parameters specific to a module (equivalent to the `app.yml`, but at the module level) and action configuration. Chapter 6 provides more details. 311 311 * `security.yml`: This file sets access restrictions for actions. This is where you specify that a page can be viewed only by registered users or by a subset of registered users with special permissions. Chapter 6 will tell you more about it. 312 312 * `view.yml`: This file contains configuration for the views of one or all of the actions of a module. It overrides the application `view.yml` and is described in Chapter 7. … … 468 468 ------------------------------------- 469 469 470 All the configuration files are eventually transformed into PHP, and many of the settings they contain are automatically used by the framework, without further intervention. However, you sometimes need to access some of the settings defined in the configuration files from your code (in actions, templates, custom classes, and so on). The settings defined in settings.yml, app.yml, module.yml, logging.yml, and i18n.yml are available through a special class called sfConfig.470 All the configuration files are eventually transformed into PHP, and many of the settings they contain are automatically used by the framework, without further intervention. However, you sometimes need to access some of the settings defined in the configuration files from your code (in actions, templates, custom classes, and so on). The settings defined in `settings.yml`, `app.yml`, `module.yml`, `logging.yml`, and `i18n.yml` are available through a special class called `sfConfig`. 471 471 472 472 ### The sfConfig Class … … 492 492 The environment is not included, since your PHP code will have access only to the values defined for the environment in which it's executed. 493 493 494 For instance, if you need to access the values defined in the app.ymlfile shown in Listing 5-15, you will need the code shown in Listing 5-16.494 For instance, if you need to access the values defined in the `app.yml` file shown in Listing 5-15, you will need the code shown in Listing 5-16. 495 495 496 496 Listing 5-15 - Sample `app.yml` Configuration … … 587 587 588 588 >**TIP** 589 >Each time you are tempted to define a constant or a setting in one of your scripts, think about if it would be better located in the app.ymlfile. This is a very convenient place to store all application settings.589 >Each time you are tempted to define a constant or a setting in one of your scripts, think about if it would be better located in the `app.yml` file. This is a very convenient place to store all application settings. 590 590 591 591 When your need for custom parameters becomes hard to handle with the `app.yml` syntax, you may need to define a syntax of your own. In that case, you can store the configuration in a new file, interpreted by a new configuration handler. Refer to Chapter 19 for more information about configuration handlers. … … 609 609 exclude: [vendor] 610 610 611 The path parameter will take the value returned by sfConfig::get('sf_symfony_lib_dir'). If you want one configuration file to rely on another, you need to make sure that the file you rely on is already parsed (look in the symfony source to find out the order in which the configuration files are parsed). `app.yml` is one of the last files parsed, so you may rely on others in it.611 The path parameter will take the value returned by `sfConfig::get('sf_symfony_lib_dir')`. If you want one configuration file to rely on another, you need to make sure that the file you rely on is already parsed (look in the symfony source to find out the order in which the configuration files are parsed). `app.yml` is one of the last files parsed, so you may rely on others in it. 612 612 613 613 ### Using Scriptable Configuration
