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




Def setting():

These will be imported into the models so will run before the models and for the first time only The settings layout needs to be stored in here. The settings is a dict with keys as the:



 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.

We will have to set the settings in accordance with modules/s3/

Def 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)

Note: See TracWiki for help on using the wiki.