Changes between Version 39 and Version 40 of BluePrintWebSetup

01/05/15 12:52:37 (7 years ago)
Fran Boon

Deprecate Old Info


  • BluePrintWebSetup

    v39 v40  
    11= Blueprint for Web Setup =
    3 This document is old. It has been superseded by DeveloperGuidelines/WebSetup
    4 == Status ==
    5 Video Demo:
     4Allow access via Web UI to be able to edit
    7 Source:
    8  *
    9 === !ToDo ===
    10 ==== Packaging ====
    11 We need to think about how we package this since it's designed as a parallel app to eden, so would normally sit at the same level as the
    12 current repo's root folder. Don't really want to move the root up one as then we'll find it harder to maintain parallel app versions.
     6This is probably best done by extending the Setup co-application:
    14 Thinking about storing it within /eden but then having it copy this stuff out to the root applications folder on run, if it's not there
    15 already....thinking about how it updates that version & how we'd manage with eden, eden2, eden_test as alternate app versions...
    17 I'm thinking we could just have 'eden/private/setup' copied to 'setup'.
    18 This could be done if a flag is set in deployment settings to do this.
    19 This should be the first flag read:
    20 {{{
    21 deployment_settings.base.websetup = True
    22 }}}
    23 If True then copy all the files from private to the new app & redirect user there.
    24 Once websetup has completed then change this flag to False.
    25 From thenceforth users would only get back to websetup if they explicitly requested it, which could be done via the admin menu.
    26 ==== Maintainability ====
    27 I think we should look to redesign this somewhat:
    28  1. Pull all setting options from & current settings from
    29 Remember that the idea is that web setup can be run after the initial install to make subsequent settings changes (ideally just single
    30 pages, but skipping unchanged pages via Next is fine for now).
    31 The validation for fields needs to be pushed back into s3cfg so that these get maintained together & can be read by setup when it imports
    32 from there (other than what you're doing in the view for password & HMAC key - these can stay as-is).
    34  2. Don't do a full write-out of the 000_config file.
    35 Instead just touch what we know - i.e. parse the existing file & just change lines that we know.
    36 If a line doesn't exist (either commented or active) then can add it from the information in s3cfg.
    37 If a line does exist (either commented or active) then can uncomment & set to what has been requested.
    38 All other lines should be ignored.
    39 This would seem a more robust, less intrusive system.
    40 I can foresee that deployers will add their own customisations into 000_config & won't push this into s3cfg or setup & will get upset if their customisations disappear...
    42 ==== i18n ====
    43  * all user-visible strings should be wrapped in T()
    45 ==== Other things to include ====
    46  * Template version of 000_config
    48 == Other Options ==
    50 Web2Py now has a Wizard setup from which ideas (& maybe code?) can be borrowed:
    51  *
    53 == Requirements ==
    54  * Provide a 1st-time configuration screen.
    55  * Provide a way to amend settings for a live deployment.
    56   * Ideally re-using the same screens
    57  * Provide a way to install sample data (like lists of organisations) etc for a deployment. Basically, data pre-population will have data that novice users (and even advanced users) will find useful when they are using the system. Of course, database connection info is needed before any data can be put into the tables.
    59 Setting the 1st username/password here & then running {{{models/}}} means that:
    60  * User can be given admin rights even on databases which support referential integrity.
    61   * MySQL can:
    62 {{{
    64 do import
    66 }}}
    68 Configuration settings are in the file {{{models/}}} which will have a simple structured format.
    69  * {{{models/}}} reads these settings to do the actual configuration.
    70  * The Web Setup should ideally read in the {{{}}} file, make any amendments as-required & then write it out.
    71  * This means that developers can edit the settings live (we remain RAD) & there are no unncessary DB calls every request.
    72  * Ideally the Web setup should have a UI which works via introspection, so doesn't need to be maintained separately when settings are added/amended (this means the settings file needs to include labels/help text).
    73  * instantiates the '''S3Config''' class as ''deployment_settings'':
    74    * S3Config is a subclass of ''Storage'' and can therefore be written in dot-notation
    75    * S3Config implements methods to read the config values (instead of accessing the instance attributes themselves), which also implement any fallback values. These methods should be used throughout the application (=do not store their return values in any global variables).
    76    * additionally, a S3Config instance could (should) be made read-only during the current request (=safer) by amending the ''!__setattr!__'' method to not accept updates
    77    * S3Config could contain a method to generate a web form to create a new instance (+pre-populate the form with values of another instance)
    78    * S3Config could then even contain a method to write the instance to a config file like
    80 There should be an option to be able to run with settings in the DB instead of config file to support:
    81  * Load-balanced webservers
    82  * GAE
    84 Provide an option to import themes of settings (e.g. 'FEMA') using {{{shn_import}}} from CSV files in {{{private/import}}}:
    85  * Symbology (icons on maps)
    86  * Terminology of Labels
    87  * Forms used (which fields are used, which are mandatory, etc)
    88  * Which modules are active
     9== See Also ==
    9012Sahana Phase2 version:
    91  *
    92  *
    94 ----
    95 BluePrints