Help-Site Computer Manuals
  Algorithms & Data Structures   Programming Languages   Revision Control
  Cameras   Computers   Displays   Keyboards & Mice   Motherboards   Networking   Printers & Scanners   Storage
  Windows   Linux & Unix   Mac

the configuration handler for Jifty

Jifty::Config - the configuration handler for Jifty


Jifty::Config - the configuration handler for Jifty


  my $app_name = Jifty->config->framework('ApplicationName');

  my $frobber  = Jifty->config->app('PreferredFrobnicator');


This class is automatically loaded during Jifty startup. It contains the configuration information loaded from the config.yml file (generally stored in the etc directory of your application, but see load for the details). This configuration file is stored in YAML format.

This configuration file contains two major sections named ``framework'' and ``application''. The framework section contains Jifty-specific configuration options and the application section contains whatever configuration options you want to use with your application. (I.e., if there's any configuration information your application needs to know at startup, this is a good place to put it.)



In general, you never need to call this, just use:


in your application.

This class method instantiates a new Jifty::Config object. This object deals with configuration files.

PARAMHASH currently takes a single option

This boolean defaults to true. If true, load will be called upon initialization.


Jifty first loads the main configuration file for the application, looking for the JIFTY_CONFIG environment variable or etc/config.yml under the application's base directory.

It uses the main configuration file to find a vendor configuration file -- if it doesn't find a framework variable named 'VendorConfig', it will use the JIFTY_VENDOR_CONFIG environment variable.

After loading the vendor configuration file (if it exists), the framework will look for a site configuration file, specified in either the framework's SiteConfig or the JIFTY_SITE_CONFIG environment variable. (Usually in etc/site_config.yml.)

After loading the site configuration file (if it exists), the framework will look for a test configuration file, specified in either the framework's TestConfig or the JIFTY_TEST_CONFIG environment variable.

Note that the test config may be drawn from several files if you use the Jifty::Test manpage. See the documentation of the Jifty::Test::load_test_configs manpage.

Values in the test configuration will clobber the site configuration. Values in the site configuration file clobber those in the vendor configuration file. Values in the vendor configuration file clobber those in the application configuration file. (See WHY SO MANY FILES for a deeper search for truth on this matter.)

Once we're all done loading from files, several defaults are assumed based on the name of the application -- see guess.

After we have the config file, we call the coderef in $Jifty::Config::postload, if it exists. This last bit is generally used by the test harness to do a little extra work.

SPECIAL PER-VALUE PROCESSING: If a value begins and ends with ``%'' (e.g., ``%bin/foo%''), converts it with Jifty::Util/absolute_path to an absolute path. This is typically unnecessary, but helpful for configuration variables such as MailerArgs that only sometimes specify files.

framework VARIABLE

Get the framework configuration variable VARIABLE.


Get the application configuration variable VARIABLE.


Attempts to guess (and return) a configuration hash based solely on what we already know. (Often, in the complete absence of a configuration file). It uses the name of the directory containing the Jifty binary as a default for ApplicationName if it can't find one.


Returns a default guessed config for a new application.

See the Jifty::Script::App manpage.

update_config $CONFIG

Takes an application's configuration as a hashref. Right now, it just sets up plugins that match an older jifty version's defaults


We have a couple default values that shouldn't be included in the ``guessed'' config, as that routine is used when initializing a new application. Generally, these are platform-specific file locations.

load_file PATH

Loads a YAML configuration file and returns a hashref to that file's data.


The Jifty configuration can be loaded from many locations. This breakdown allows for configuration files to be layered on top of each other for advanced deployments.

This section hopes to explain the intended purpose of each configuration file.


The first configuration file loaded is the application configuration. This file provides the basis for the rest of the configuration loaded. The purpose of this file is for storing the primary application-specific configuration and defaults.

This can be used as the sole configuration file on a simple deployment. In a complex environment, however, this file may be considered read-only to be overridden by other files, allowing the later files to customize the configuration at each level.


The vendor configuration file is loaded and overrides settings in the application configuration. This is an intermediate level in the configuration. It overrides any defaults specified in the application configuration, but is itself overridden by the site configuration.

This provides an additional layer of abstraction for truly complicated deployments. A developer may provide a particular Jifty application (such as the Wifty wiki available from Best Practical Solutions) for download. A system administrator may have a standard set of configuration overrides to use on several different deployments that can be set using the vendor configuration, which can then be further overridden by each deployment using a site configuration. Several installations of the application might even share the vendor configuration file.


The site configuration allows for specific overrides of the application and vendor configuration. For example, a particular Jifty application might define all the application defaults in the application configuration file. Then, each administrator that has downloaded that appliation and is installing it locally might customize the configuration for a particular deployment using this configuration file, while leaving the application defaults intact (and, thus, still available for later reference). This can even override the vendor file containing a standard set of overrides.




Various folks at BestPractical Solutions, LLC.


Jifty is Copyright 2005-2007 Best Practical Solutions, LLC. Jifty is distributed under the same terms as Perl itself.