Development

HowToPlanConfigurationPlacement (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of HowToPlanConfigurationPlacement

Show
Ignore:
Author:
anonymous (IP: 24.113.22.109)
Timestamp:
07/22/06 22:49:53 (11 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • HowToPlanConfigurationPlacement

    v0 v1  
     1== Configuration Handling == 
     2 
     3Preface: It took my awhile to fine tune my placement of configuration settings as I built my first Symfony application. Maybe the notes below will get you to proper config placement quicker than me. 
     4 
     5The default configuration handling for symfony allows you to set the configuration of the current request based on both the environment (test, production, dev, etc) as well as the location of request (proj, app, module). When using the default configuration files it works really well to set settings for a single application or a single module, but for many settings you need more flexibility. 
     6 
     7In particular, we often need a settings array for multiple apps or modules within the project but we may not want to load the settings for every single request unless they are needed. For this reason, we do some special loading of global settings on an as needed bases. 
     8 
     9For example, the listings have checkbox set options (Utilities Included => Water, Sewer, Garbage, etc) that we will need in the frontend app when we edit the listing, in the sites app when we show the listing, and in the backend app when we force editing of a listing by the admin. There are two ways to get these settings across all apps: 
     10 
     11 * load the setting for every request in all apps 
     12 * load the setting only when needed from a global settings folder 
     13 
     14We have chosen to use the second option so the application runs quicker. So for our listings example, we need the settings in the frontend whenever working with the listings module. So we add and edit: 
     15 
     16 
     17And we include a request to load global settings like: 
     18{{{ 
     19/frontend/modules/listings/config/config.php: 
     20 
     21sfConfig::add(sfYaml::load(sfConfig::get('sf_config_global_dir').DIRECTORY_SEPARATOR.'listings.yml')); 
     22}}} 
     23 
     24NOTE: We add sf_config_global_dir setting in /config/config.php with this line:  
     25{{{ 
     26sfConfig::set('sf_config_global_dir', sfConfig::get('sf_config_dir').DIRECTORY_SEPARATOR.'global');   
     27}}} 
     28 
     29This will then load our options into the sfConfig settings for the listings. Then when we need these same options in the sites app we just add the same line to: 
     30 
     31 * /sites/modules/listings/config/config.php 
     32 
     33and same for backend. This way we get global (project level) config settings but only when we need them. 
     34 
     35== General Rules for Config Placement == 
     36 
     37If the setting will be likely be used in more than one app: 
     38 
     39 * If the setting will be used in most modules or all requests, put in /config/config.php 
     40 * If only in a couple modules per app, put in /config/global/ and load when needed using method above. 
     41 
     42If the setting will definitely ONLY be used in ONE app: 
     43 
     44 * If used in ONLY ONE module, put in /apps/app_name/modules/config/module.yml 
     45 * If used in several modules in app, put in /apps/app_name/config/app.yml