Each configuration file has a handler. The job of configuration handlers is to manage the configuration cascade, and to do the translation between the configuration files and the optimized PHP code executable at runtime.
The default handler configuration is stored in $sf_symfony_data_dir/config/config_handlers.yml. This file links the handlers to the configuration files according to a file path. Listing 19-7 shows an extract of this file.
config/settings.yml:
class: sfDefineEnvironmentConfigHandler
param:
prefix: sf_
config/app.yml:
class: sfDefineEnvironmentConfigHandler
param:
prefix: app_
config/filters.yml:
class: sfFilterConfigHandler
modules/*/config/module.yml:
class: sfDefineEnvironmentConfigHandler
param:
prefix: mod_
module: yes
For each configuration file (config_handlers.yml identifies each file by a file path with wildcards), the handler class is specified under the class key.
The settings of configuration files handled by sfDefineEnvironmentConfigHandler can be made available directly in the code via the sfConfig class, and the param key contains a prefix value.
$ cat /www/admin_generator/data/symfony/config/module.yml default: enabled: on view_class: sfPHP is_internal: off
$ cd /www/sfdemo/apps/backend
$ ls -1 config/*.yml config/app.yml config/cache.yml config/factories.yml config/filters.yml config/i18n.yml config/logging.yml config/routing.yml config/security.yml config/settings.yml config/view.yml
$ ls -1d modules/* modules/author modules/category modules/post
$ cat /www/sfdemo/cache/backend/dev/config/modules_author_config_module.yml.php <?php // auto-generated by sfDefineEnvironmentConfigHandler // date: 2007/01/29 22:33:38 sfConfig::add(array( 'mod_'.strtolower($moduleName).'_enabled' => true, 'mod_'.strtolower($moduleName).'_view_class' => 'sfPHP', 'mod_'.strtolower($moduleName).'_is_internal' => false, ));
Using a handler to deal with a configuration file provides two important benefits:
The configuration file is transformed into executable PHP code, and this code is stored in the cache. This means that the configuration is parsed only once in production, and the performance is optimal.
The configuration file can be defined at different levels (project and application) and the final parameter values will result from a cascade. So you can define parameters at a project level and override them on a per-application basis.
If you just need to allow users to retrieve values from the code via sfConfig, you can use the sfDefineEnvironmentConfigHandler configuration handler class.
For instance, to have the url and user parameters available as sfConfig::get('map_url') and sfConfig::get('map_user'), You may want to store these two parameters in a custom configuration file called map.yml, located in the application config/ directory. This configuration file might contain the following:
api: url: map.api.example.com user: foobar
And define your handler as follows:
config/map.yml:
class: sfDefineEnvironmentConfigHandler
param:
prefix: map_
Be careful not to choose a prefix already used by another handler. Existing prefixes are sf_, app_, and mod_.
When you need the code based on the map.yml file and generated by the myMapConfigHandler handler in your application, call the following line:
include(sfConfigCache::getInstance()->checkConfig(sfConfig::get('sf_app_config_dir_name').'/map.yml'));
When calling the checkConfig() method, symfony looks for existing map.yml files in the configuration directories and processes them with the handler specified in the config_handlers.yml file.
> I mean a custom yml file in /config that can be parsed and cached just like > app.yml.
I added test.yml in /myapp/config/ and changed the config_handlers.php like the following:
config/test.yml:
class: sfDefineEnvironmentConfigHandler
param:
prefix: test_
(I missed ":" in the test.yml at first)
I added one line in myapp/config/config.php
require_once(sfConfigCache::getInstance()->checkConfig(sfConfig::get('sf_app_config_dir_name').'/test.yml'));
It works!
documented on: 16 July 2007, cysin
I'm using set of yml files for an additional config, all handled by sfDefineEnvironmentConfigHandler.
my config_handlers.yml:
config/my_settings.yml:
class: sfDefineEnvironmentConfigHandler
param:
prefix: my_glob_settings_
modules/*/config/my_settings.yml:
class: sfDefineEnvironmentConfigHandler
param:
prefix: my_mod_settings_
module: yes
The config/my_settings.yml file is being parsed and cached nicely, however I cannot get it to work on the module level.
Problem solved, caused by a missing slash in function returning full path to the module's yml file
What are the differences between templates and plain .php files?
I.e., in a pure .php file, how can I use features that available to templates?
E.g.,
<?php use_helper('Debug') ?>
<?php log_message($message, $level) ?>
You can always access the helpers from outside the view by loading them first:
sfLoader::loadHelpers('Url');
documented on: 2007.07.17, snowkrash
how to use getRequestParameter in partial?
In the partial template of a partial field can access to the current object "through a variable named by the class ($comment in this example). " http://www.symfony-project.org/book/trunk/14-Generators
So, I've copied and changed from
$this->getRequestParameter('id')
to:
$comment->getRequestParameter('id')
in my partial, but this is what I get.
Fatal error: Call to undefined method Comment::getRequestParameter() in /var/www/html/cm/apps/reqs/modules/comment/templates/_comments.php
please help. thanks
in partials:
$sf_request->getParameter('id');
or
$sf_params->get('id');
see:
documented on: 06 February 2007, pezetgee
If I create a general purpose class for use in my symfony application, is there a best place to put it?
If you want the classes to be available only to particular app place them in:
yourproject/apps/yourapp/lib/
If they should be available to all apps:
yourproject/lib/
documented on: 23 March 2007, pezetgee
Lib folder, both (or any) lib folder, as mentioned a few times in the documentation. Classes inside get autoloaded, if you clear the cache. This way you don't need any includes or requires …
documented on: 23 March 2007, michael.piecko
"If the size of an action class grows too much, you probably need to do some refactoring and move some code to the model layer." http://www.symfony-project.org/book/trunk/06-Inside-the-Controller-Layer#The%20Action%20Class
The question is, how do I do that?
I mean, how to translate action's $this, e.g.,
$this->getUser()... $this->getRequestParameter...
I guess this question is so common-sense to PHP that it is not even covered in the book (controller & model section).
> $this->getUser()... > $this->getRequestParameter...
sfContext::getInstance()->getUser() sfContext::getInstance()->getRequest()->getParameter
This is "is just a little messy, and quite repetitive if used more than once.".
If you want to solve it systematically, ie, to "farm out action logic to static functions in a class in my application or module lib/ directory.", check out this:
documented on: 06 March 2007, sfxpt
