| 18 | |
| 19 | ==== Maintainability ==== |
| 20 | I think we should look to redesign this somewhat: |
| 21 | 1. Pull all setting options from s3cfg.py & current settings from 000_config.py. |
| 22 | Remember that the idea is that web setup can be run after the initial install to make subsequent settings changes (ideally just single |
| 23 | pages, but skipping unchanged pages via Next is fine for now). |
| 24 | 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 |
| 25 | from there (other than what you're doing in the view for password & HMAC key - these can stay as-is). |
| 26 | |
| 27 | 2. Don't do a full write-out of the 000_config file. |
| 28 | Instead just touch what we know - i.e. parse the existing file & just change lines that we know. |
| 29 | If a line doesn't exist (either commented or active) then can add it from the information in s3cfg. |
| 30 | If a line does exist (either commented or active) then can uncomment & set to what has been requested. |
| 31 | All other lines should be ignored. |
| 32 | This would seem a more robust, less intrusive system. |
| 33 | 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... |
| 34 | |
| 35 | ==== i18n ==== |
| 36 | * all user-visible strings should be wrapped in T() |