wiki:BluePrint/Templates

Version 19 (modified by Fran Boon, 12 years ago) ( diff )

--

BluePrint: Templates

Table of Contents

  1. Introduction
  2. Description
  3. Requirements
  4. Use-Cases
    1. End-User wishing to trial the System
    2. Deployer
    3. Developer/Tester
    4. Trunk Maintainer
  5. Design
    1. Future extensions
  6. Implementation
  7. References

Introduction

Templates allow selecting alternate configuration sets.

This allows a separation between Core Code & Settings/Custom Code.

This helps prevent merge conflicts between different deployment branches & hence reduces the risk of forking.

Description

Builds on the 000_config.py configuration template and DeveloperGuidelines/PrePopulate.

Requirements

See Use-Cases

Use-Cases

End-User wishing to trial the System

The end-user would like to download & run immediately with the minimimum of up-front configuration possible - the defaults should be sufficient to get started with.

If they must select between alternate options then they'd definitely want this to be done through the web browser.

  • perhaps the most useful would be a single web page with a list of Templates to choose from, with a big button to say 'OK' to proceed with the default.

Once they've played around some & wish to customise it, then they would like to be able to configure options via WebSetup.

Once they decide to go into production, it would be really useful to be able to save all the settings they've made in their local instance to a file & then use this file to configure their server instance. This could include population of lookup lists being saved as CSVs and then compressing these into a single file to be uncompressed on the server.

Deployer

The deployer wants to be walked through the different settings...ideally through a WebSetup Wizard, however they're OK at doing this through a text file or CLI prompts if-required.

They want to minimise the number of interrupts during the setup process - i.e. they would like to run a single script to download/install all the software & then run through a single set of configuration options. The current supported installation scripts do this reasonably well, e.g. InstallationGuidelines/Linux/Server/CherokeePostgreSQL

Developer/Tester

The developer/tester would like to be able to quickly move their system between different configuration options. This would typically happen as part of their 'clean' script, so could be done via the CLI

They would like to distinguish between the settings which relate to the profile template from the settings which are about their machine instance (Debug, SMTP, Database, API Keys, etc)

They would like to select between prepopulate options when using a single configuration template. e.g. IFRC 000_config.py can be used with IFRC, IFRC_Train or ["IFRC_Train", "IFRC_Demo"], but we don't want to have to maintain 3x 000_config.py files.

Trunk Maintainer

The old deployment_templates/000_config.py always had regular merge conflicts with deployment branches, so separating these into separate template folders should improve things.

We would like to minimise the differences between the different templates so all the non-default ones should only enable what they need in order to minimise maintenance.

Design

Configuration is done using these files:

  • /private/templates/000_config.py
  • /private/templates/default/config.py
  • /private/templates/<template>/config.py

During 1st_run, 000_config.py is copied to models/

000_config.py includes:

  • FINISHED_EDITING_CONFIG_FILE
  • VERSION
  • machine-specific configuration (Debug, Database, SMTP, API Keys, etc)
  • a setting to define which template folder to run
  • importing of settings from templates/<template>/config.py
  • optional local overrides to the template's settings

Prepopulate options are defined in the template's config.py

Future extensions

These are proposed extensions which need refining:

Message Parser:

  • private/templates/<template>/parser.py
    • imported into modules/s3/s3msg.py

Tasks:

  • private/templates/<template>/tasks.py
    • imported into models/tasks.py

Theme:

  • static/styles/<template>/style.css
  • static/img/<template>/*.png
  • views/<template>/layout.html
  • controllers/default.py index()

Menus:

  • private/templates/<template>/menus.py
    • subclasses modules/eden/menus.py to allow overrides
  • private/templates/<template>/layouts.py
    • subclasses modules/eden/layouts.py to allow overrides
  • models/01_menu.py should no longer be required

Fields:

  • private/templates/<template>/fields.py
    • includes any local overrides to field labels/readable/writable/DAL-level required
  • modules/s3/s3fields.py
    • S3Field to subclass Field to read settings from fields.py

Implementation

Implmentation Steps for the next phase (no 'future extensions' yet)

  1. git mv /private/templates/demo/* /private/templates
    • move all contents of 'demo' up 1 level for consistency to find across all functions which use templates
  2. split 000_config.py into 2 files:
    • Machine-specific configuration (Debug, SMTP, Database, API Keys, etc): /private/templates/000_config.py
    • Instance-type configuration: /private/templates/<template>/config.py
  3. revert CANARY_UPDATE_CHECK_ID to using 0000_update.py
  4. make update_check remove 0000_template.py
  5. make update_check check the VERSION of the 000_config.py file
  6. make update_check backup any old 000_config.py which is present (rename as 000_config.bak)
  7. update the CANARY_UPDATE_CHECK_ID to force update_check to run

References

BluePrints

Note: See TracWiki for help on using the wiki.