InterJinn

Development Framework For PHP

Templating System Configuration

Templating systems are designed to separate content from logic and provide a means to rapidly make sweeping changes to an entire site. By defining the layout of a Web site in a template, the layout for the entire site can be changed by updating the content in that single template. Alternatively many aspects of the layout can be broken out into sub-templates. Candidates for such sub-templating are things like navigation, headers, and footers. The following sections describe how to configure InterJinn to enable the TemplateJinn system.

Templating Configuration

$GLOBALS['interJinn']['compileUpdates']

Setting this to true will facilitate the automatic recompilation of any pages for which the dependencies have changed. A dependency is considered to have changed when its timestamp is newer than the target it helped to create. This also facilitates the automatic compilation of any pages that have been added to the page patterns but which have never been compiled.

Example:
$GLOBALS['interJinn']['compileUpdates'] = true;

$GLOBALS['interJinn']['compileSourcePath']

This defines a standardized location for the TemplateJinn framework to find your content source files. If this path is prefixed by a forward slash (/) then the location will be considered relative to the root of the filesystem. Alternatively, if the path is prefixed with two forward slashes (//) or none at all, then it will be considered relative to the value of the $GLOBALS['interJinn']['codeRoot'] configuration variable. NOTE: if you decide to mix content loading mechanisms (i.e. sql:// and file:// then you will need to ensure all content entries in the database table have the same path structure as the filesystem.

Example:
$GLOBALS['interJinn']['compileSourcePath'] =
    'InterJinn/build/sources/';

$GLOBALS['interJinn']['compileTemplatePath']

This defines a standardized location for the TemplateJinn framework to find your template files. If this path is prefixed by a forward slash (/) then the location will be considered relative to the root of the filesystem. Alternatively, if the path is prefixed with two forward slashes (//) or none at all, then it will be considered relative to the value of the $GLOBALS['interJinn']['codeRoot'] configuration variable. NOTE: if you decide to mix content loading mechanisms (i.e. sql:// and file:// then you will need to ensure all content entries in the database table have the same path structure as the filesystem.

Example:
$GLOBALS['interJinn']['compileTemplatePath'] =
    'InterJinn/build/templates/';

$GLOBALS['interJinn']['compileFilePath']

This defines a standardized location for the TemplateJinn framework to find any miscellaneous content files. If this path is prefixed by a forward slash (/) then the location will be considered relative to the root of the filesystem. Alternatively, if the path is prefixed with two forward slashes (//) or none at all, then it will be considered relative to the value of the $GLOBALS['interJinn']['codeRoot'] configuration variable. NOTE: if you decide to mix content loading mechanisms (i.e. sql:// and file:// then you will need to ensure all content entries in the database table have the same path structure as the filesystem.

Example:
$GLOBALS['interJinn']['compileFilePath'] =
    'InterJinn/build/files/';

$GLOBALS['interJinn']['compileTargetPath']

This determines where TemplateJinn will place all of your compiled targets. If this path is prefixed by a forward slash (/) then the location will be considered relative to the root of the filesystem. Alternatively, if the path is prefixed with two forward slashes (//) or none at all, then it will be considered relative to the value of the $GLOBALS['interJinn']['pageRoot'] configuration variable.

Example:
$GLOBALS['interJinn']['compileTargetPath'] = '';

$GLOBALS['interJinn']['compileMaxCount']

Sometimes the template compiler can run amuck. Usually this happens when the file permissions are not set properly and it keeps thinking there is new content. To combat this issue the compiler keeps track of an index and when it reaches a maximum count (within a timeframe) it will stop trying to generate the target content. This parameter determines just how high that count may go in the timeframe before the compiler stops. The default for this value is 5.

Example:
$GLOBALS['interJinn']['compileMaxCount'] = 10;

$GLOBALS['interJinn']['compileTimeframe']

This parameters is used in conjunction with the $GLOBALS['interJinn']['compileMaxCount'] parameter to determine the timeframe in seconds after which the count is reset back to 0. If the count reaches it's maximum in this timeframe then compilation ends. The default for this parameter is 20 seconds.

Example:
$GLOBALS['interJinn']['compileTimeframe'] = 15;

Content Manager Configuration

$GLOBALS['interJinn']['contentDefaultType']

This determines the default content type to use for a content path when the type identifier has been omitted. This was added for historical reasons, but also offers a shorthand for declaring content paths when most or all of your content is stored in a single respository type. For more information about content types, you should see the Content Manager Service documentation.

Example:
$GLOBALS['interJinn']['contentDefaultType'] = 'file';

$GLOBALS['interJinn']['contentDatabase']

Set this to the name of the database in which you keep your content table for retrieval via the sql content path type. Note that by name, we mean one of the names declared in the database configuration section or if you wish, a fully described database configuration array, also described in the database configuration section. The default database is used when this is not set.

Example:
$GLOBALS['interJinn']['contentDatabase'] = 'someDatabase';

$GLOBALS['interJinn']['contentTablePrefix']

When this has been set, all tables accessed by the sql content loader object will be prefixed with the given value. This makes it possible to use InterJinn SQL content loading within a pre-existing site that may already use any of the required table names.

Example:
$GLOBALS['interJinn']['contentTablePrefix'] = 'interjinn_';

Database Patterns Configuration

$GLOBALS['interJinn']['pagePatternSystem']

Setting this to database indicates that you are using page patterns defined in the standard page_patterns database table.

Example:
$GLOBALS['interJinn']['pagePatternSystem'] = 'database';

$GLOBALS['interJinn']['pagePatternDatabase']

When this has not been set, then the InterJinn database declaration with the name default is used for all database page patterns. The value of this may either be a name of a declared database or an array containing the appropriate database connection parameters as described in the database declaration section.

Example:
$GLOBALS['interJinn']['pagePatternDatabase'] = 'someOtherDatabase';

$GLOBALS['interJinn']['pagePatternTablePrefix']

When this has been set, all tables accessed by the page pattern service will be prefixed with the given value. This makes it possible to use InterJinn database page patterns within a pre-existing site that may already use any of the required table names.

Example:
$GLOBALS['interJinn']['pagePatternTablePrefix'] = 'interjinn_';

Filesystem Patterns Configuration

$GLOBALS['interJinn']['pagePatternSystem']

Setting this to file indicates that you are using page patterns defined in a pattern file located on the filesystem.

Example:
$GLOBALS['interJinn']['pagePatternSystem'] = 'file';

$GLOBALS['interJinn']['pagePatternDataPath']

Set this to the location of your pattern file. The file should contain the patterns for compiling your target pages.

Example:
$GLOBALS['interJinn']['pagePatternDataPath'] =
    '/var/www/apps/interJinn/data/yourProject/patterns.txt';