You're not currently signed in.

Understanding the config file

Every Jifty Application uses a config file, etc/config.yml to control its operation. In absence of a config file, all values are guessed with reasonable defaults. The config file is in yaml format, which is described on the YAML Homepage.

A sample config file

A typical minimal config file looks like this:

---
framework:
  AdminMode: 1
  ApplicationClass: DemoApp
  ApplicationName: DemoApp
  Database: 
    Database: demoapp
    Driver: SQLite
    Host: localhost
    Password: ''
    RecordBaseClass: Jifty::DBI::Record::Cachable
    User: ''
    Version: 0.0.1
  DevelMode: 1
  L10N: 
    PoDir: share/po
  LogLevel: INFO
  Mailer: Sendmail
  MailerArgs: []

  Plugins:
    - Login: {}

  Web: 
    BaseURL: http://localhost
    DataDir: var/mason
    Globals: []

    MasonConfig: 
      autoflush: 0
      default_escape_flags: h
      error_format: text
      error_mode: fatal
    Port: 8888
    ServeStaticFiles: 1
    StaticRoot: share/web/static
    TemplateRoot: share/web/templates

Accessing config entries

Note that the top level key in this config file is framework. Inside Jifty, you might access any point under this key by simply using Jifty->config->framework->('some_key')->{whatever}.

If you like to define some structure of your own, Jifty reserves the top level keyword application whose entries can get accessed by using Jifty->config->app->('some_key')->{whatever}.

If you intend to edit the config file by hand, be sure that you understand the basics of the YAML format. Please do not change the indentation of lines and ensure your editor will not replace series of spaces by tab characters.

Understanding the entries

The most interesting keys are:

  • framework/AdminEmail

    The mail address of your admin.

  • framework/AdminMode

    If this switch is set to '1' (or a value that renders to a boolean "true" value to be precise), the administration mode is enabled in the frontend. The default templates will add a red bar displaying a hint and add some administrative entries into the page navigation bar. Internally, the user currently browsing through the application will by default be a superuser if not logged in.

  • framework/ApplicationClass

    This is the class name that builds the top level of all application classes. All model and action classes will get searched in this namespace.

  • framework/ApplicationName

    The name of the application will be displayed in some templates eg. as a title or in greeting messages after successful signup.

  • framework/Database

    Here, the database to get used is specified. The keys under this one control the vendor as well as the credentials and the dsn to access the database. Special Keys: CheckSchema

  • framework/DevelMode

    If this switch holds '1' (or another true value) the application will be optimized for developing. This includes refreshing of modules, as well as accessing all JavaScript and CSS files as single requests. If devel-mode is switched off, no module refreshing will be done and the whole JavaScript and all CSS definitions will get accessed by one request each.

  • framework/L10N

    Controls the locations where localization files can be found. Keys here are Lang, PoDir and DefaultPoDir.

  • framework/LogConfig

  • framework/LogReload

  • framework/LogLevel

    Defines the operation and verbosity of logging.

  • framework/Mailer

  • framework/MailerArgs

    Specifies the mailer to get used when a notification will get sent out by Jifty::Notification.

  • framework/MaxAttachmentSize

    Tells Jifty the maximum length of attachments. This value is used to control Jifty::DBI's LongReadLen. The current default value is 10 Million Bytes.

  • framework/Plugins

    holds an array of plugins to get loaded during application startup.

  • framework/PubSub/Enable

    This boolean value decides if the PubSub subsystem should get enabled.

  • framework/PubSub/Backend

    Controls which backend should be used to drive the PubSub functionality. Currently Memcached and JiftyDBI is possible.

  • framework/Web

    controls the operation of the web frontend and knows the following entries:

    • framework/Web/BaseURL

    defines the base url of the Jifty application. It is used to build URLs inside Jifty.

    • framework/Web/DataDir

    this relative path defines where mason stores its cached entries. It defaults to var/mason.

    • framework/Web/FastCGI

    Here, some configuration entries for FastCGI operation are stored. Currently, the only key here is MaxRequests.

    • framework/Web/Globals

    Typically mason runs under 'strict' mode forbidding global variables. If you really need to use global variables, you might allow the globals listed here.

    • framework/Web/MasonConfig

    This entry allows to set mason config options.

    • framework/Web/Port

    The TCP port your Jifty application listens on.

    • framework/Web/SkipDatabase

    No database will be used if true.

    • framework/Web/ServerClass

    ??? write more

    • framework/Web/SessionSecret

    ??? write more

    • framework/Web/ServeStaticFiles

    Specifies if Jifty's handler should serve static files. Please keep in mind that static files are distributed across your application, Jifty's default application as well as all plugins.

    • framework/Web/StaticRoot
    • framework/Web/TemplateRoot

    These two keys specify the relative directories where Jifty searches static and dynamic templates. The default to share/web/static and share/web/templates.