Version 4 (modified by anubhav, 13 years ago) ( diff )




Dict of settings

We will copy this file from Eden ( s3cfg can be changed to generated this file during its run )into the modules of Web Setup and make it run. These would be locally imported in the Models so they will be executed first:



 Settings = {"databse.db_type" : {"nice_name" :T("Database"), 
                                  "description":T("Database Type: "), 
                                  "options":['sqlite', 'sql', 'mysql'],
                                  "jquery_validation_requirements”: "required lettersonly"
             #and similarly other options for language can be set

These are really useful for views as this provide the information regarding input type, the value to select from, the field name and the validation requirement. These layouts are mostly for the views. Some of these like port will also contain a validation field for the range of accepted values.

Change in s3cfig to generate the dict shown above

changing s3cfg to generate this dict

1. Write 
    a."settings = {" in the starting of the dict
    b.settings_type + "." + settings_name in each get function 
    c.also specify the details like input type over there.

Thus only s3cfg will contain all the dict .

After gsoc we can also change s3cfg in the starting to generate 000_config if it is the first time of run

Dict of Modules

These needs to store the names of the modules:-

modules = {
#true meaning "on"

Here the “on” indicate that the default value of the module status is on.

In the modules the layout is not required, as they are stored when we run the modified form of 000_config in the models. The input types of these (name, Description, Access level) are quite fixed so they need not to be stored separately. Therefore not much help is required for the views to.

MODELS (This will run before the modified version of 000_config)

Session variable : session.path_to_config

This will initialize a session variable that will help us get the status of the selector. If the session variable is “none” we can initialize it to “”, and later in the controller it can be set to the path of 000_config of that particular eden they want the to the web-setup to run on. This session variable will help us to get the path of the 000_config from the controllers.


Once we get the path of 000_config we need to copy that file in the websetup models by the the name of so that it shall run after this file closes. Now open modified_config using os.path.join in the “w” mode and 000_config in the “r” mode. We need to read 000_config and This would result in the creation of 2 dicts one is deployment_settings and the other one is for the modules deployment_settings.modules .Now 6th and 7th steps will help us to maintain the dicts for modules that were turned off by commenting them.


1.Remove the line containing “s3base.s3config(” from the starting of the file


2. Insert

“ from import Storage

from gluon.contrib.simplejson.ordered_dict import OrderedDict

deployment_settings = Storage( “   

before the first line where they find  “deployment_settings.” Without a “#”  in the           

3. And add “ ) ” Immediately before the import of storage and remove the import of storage from there


4. Add 4 spaces to each line between “Storage(“ and “)” even the commented ones


5. Make the following to the lines except the ones containing “#” before the use of “deployment_settings.” 

v  Wrap each word containing “deployment_settings.” with “”

v  Add a  “,”(coma) after the line


6. Check if the    

“<?module_name?> = Storage( \n” has a “#” in the same line then turn

module[module_name] ( variable in in modules )   off .


7.Remove “#” from there till the line you get “#),”


Handling database conflicts

There should be a list that will keep a list of databse_name and database_types of 2 eden application cannot be same at same time therefore a list of database types and databse names needs to be made

  • For this we will first have to generate a list paths .We can search for “Copyright: 2010 (c) Sahana Software Foundation” in all the LICENSE files of applications.

Then we will have to search in the list of paths for specific keywords like “deployment_setting.database.database” This can be done using regex command in grep

If  path(variable) is in the list of paths containing: 
    Command_line = “grep ” +  “deployment_setting.database.database” + “path”
    Line = subprocess.Popen(command_line); 

Now search the file for deployment_settings.database.db_type .These list will help in validating for the database values. (Parsed Version OF )

It will initialize and define the dict for all the settings and the modules of whose we have mentioned before. This part of the code has not been done before. I expect to take a week at max. to complete this code.


Def selector():

If the session variable of the path is not set then I redirect the user from the index function to this function of the controller.

  • I will access the list of paths generated in the models while solving the database conflicts
  • And then there is a drop down menu to select the path ( the user will select the name, I will retrieve the path using the request.post_vars in the form.accepts and then set the path accordingly).We can create forms using SELECT() function for the dropdown and FIELDSET() for creating a filed in the form
  • This function will also contain a field for creating a new eden

Selector will also contain an option for creating new eden . This should be need no network excess, I will execute statement by “exec” for copying the files from the existing eden to a new eden with a new name. I will copy all the files except a few files like database logs, session and some other which are developed after you run the first time. After the script has run successfully

This part of the code should not take more than 4 days to code.

Def index():

If the session variable is set then this part is executed. The main purpose of this is to create forms according to the needs. We will have a submit ,back and next button on the every form .

There should be a login form that would verify that admin is making changes in the settings. For this we will have to contact the database of the selected Eden.

The TABLE() function will be extremely useful for setting the user interface and SELECT() function for defining dropboxes. INPUT() will help us define check boxes and other input types. All the fields stored in modules for every setting will be sent to the user using INPUT() (jquery validation requirement, input type and default value ) and FIELDSET(for field id and the keys of the, setting variable are extremely important here)

  • Module Forms:

Module name


Checkboxes for access level

o   Admin

o   Anonymous

o   Only Division users

o   None



Module nice name


(with correct width)


Module Description


(with correct width)




BACK(after the last module)



NEXT(after the last  module)


SAVE AND QUIT(after the last module )

  • There will be similar forms for the settings; however I would like to have separate forms for different categories of settings. Like thsese:-


(before the first setting only)


Setting name

FIELD according to the Input type required



BACK(after the last one only)



NEXT(after the last one only)


SAVE AND QUIT(after the last on only)

  • For adding some text on the main page

We will just set a text field in the form. Where he can type anything which he wants to be displayed at the main landing page of eden. I will set a global variable, that later I will write to the file 000_config.Then a division would be created in the index page of eden for displaying simple text.

In the form.accepts you will need to set the module values according to the request.post_vars.

Def write_out():

This writes data to 000_config

For this they would need to open the config using os.path.join and write data to the config  in the correct format.

Like modules needs to be done in this format:-

“deployment_settings.modules = Storge(\n” +
#For for all keys
“    “ + <?module.key?> "= Storage(\n” +
#For all keys in module.keys
“    “  + “    ” + <?keys of module.keys?> + “=” + <?values of their respective fields?> + “,\n” +
"    " + “),\n”              #after module.key
+ “)”                   #for the main

Writing settings will be much more easier, as they are not stored in dict, somewhat like:-

For all keys of settings
<?Keys of the settings ?> + “=” + <?values of the respective keys?> “\n” 

I would write default values if any request.post_var returns an invalid value according to the validation.



Though we have not talked about this part directly, however in the last section of index(): function we have talked about the forms that I would like to create. Most part of this code can be reused from the previous application.

Creating a license page :

This will be created only if “FINISHED_EDITING_CONFIG_FILE” is false in the

Sending Post Method To Get The Arguments To Controllers :

These Will Contain A Static Folder Containing The Css And The ExtJS:

This part of the code is almost reusable.


Workflow And Summary

There are 2 methods to acivate the WebSetup :

  • Going directly to the web setup this will call the selector for the path of the correct Eden . This is extremely important in the case there are more than one Eden . For this database conflicts needs to be resolved and also the
  • Either clicking on the Setup on the index page of Eden .In this case selection is not needed as the session variable will be set from the URL post

After this, the file containing the dict of settings and modules in the Eden are copied in The modules of the Web setup and made to run.

After this the 000_config is parsed to modified_config and made to run

Then we will generate a login page using the index

  • This will contact the database of the correct Eden to make the admin login if the the setup has been run once (this can be easily idebtified by the 000_config)
  • No login page if there is setup is run for the first time

The forms for each setting is displayed

The dict extracted from 000_config is writen to 000_config with the correct values

In the process I am also generating a method for creating new Eden without Netowrk Access


Getting the dictionary for the settings and the module name and status

§ We can change s3cnfg in such that the values of the dict are set just before the respective function of the key. This dict will mainly store the following things about the settings

Category, Field ids, Description, Nice name, Jquery Validation, Input type, Options etc (These things will be required by the index function of the web setup)

§ We will also copy this file in the models so that we can run this file and thus defining our dict.

§ The copying script (which copies the s3cnfg) should be kept in the controllers do that the next time the models are run the file with the dict also runs.

§ Creating this dict in s3cnfg will help to maintain the settings dict in case the settings are increased or changed

Getting the default values of the settings and the default status of the Modules

§ We shall parse the 000_config file so that it contains a dict of all the default values of settings and the values of the module.

§ The parsing script should be kept in the controllers. The parsed file is transferred to the models, so that when the next time the models, run the file with the dict also runs.


Once we have the dict of settings and modules and also there default values and status respectively we can directly go the main index function of the controllers that create forms. The data copied from the s3confg file will be extremely useful for this stage. I have also uploaded some ui mokups at (

Writing changes back in the Eden

We can use os.path to write the changes back into the 000_config. For this we shall use the modified dict (after he has changed what he wanted). The modilfed 000_config we be like the in the same format as the old one.


Note: See TracWiki for help on using the wiki.