Section 7.4. Dashboard Controller new_project


7.4. Dashboard Controller new_project

WhatWhat uses a few common JavaScript functions in its pages, and our dashboard template imports this set of master.js functions.

The major use of JavaScript in dashboard.kid is to dynamically display the new_project form.

<a href="#" onclick="toggle('new_project'); clr('ta_new_project');fcs('tf_desc'); return false;">new project</a>


This line defines an onclick event that does three important things:

  • It toggles the visibility of the new_project element.

  • It clears the text in the new_project text area field, which contains a description of the new project.

  • It clears the desc text field, which contains the project name, and moves the focus to it so that the user can just start typing.

These things are actually done by three different functions from master.js:

The toggle function takes an element_id, which in this case is the named div new_project and contains our whole form. It then checks to see that the element_id it received actually exists. Then it checks the style.display property of that element. If it's none, the function updates it to block, otherwise it changes the display property to noneeffectively telling the browser to hide that element.

But the toggle function doesn't remove the values in any of the elements in the form, so the WhatWhat onclick event also fires up the clr function passing it the "ta_new_project" element_id. This function is simple; it just looks up the element in question and replaces its value and defaultValue with an empty string. The fcs function does the same thing as clr, but it also sets the focus to the element.

After a user fills out the form, a couple of simple JavaScript statements in our template either cancel (and toggle off) or submit the form:

<a href="#" onclick="submit('form_new_project'); return false;">add</a> <a href="#" onclick="toggle('new_project'); return false;">cancel</a>


The submit function takes an element_id, looks up the form, and calls its submit method (which posts the results to the URL defined in the action attribute of the form itself):

function submit(form_id) {        document.getElementById(form_id).submit(); }


In this case, it sends the results to the relative URL /new_project, and that calls the new_project method on our dashboard controller. We said we'd come back to that method later, and here we are, so let's take a look at new_project to see how these form results are processed:

@expose() @validate(validators=dict(contact_id=validators.Int(),                           subprojects=validators.Bool())) def new_project(self, name, description, contact_id, subprojects=False):     contact = Person.get(contact_id)     main_project = Project(name=name,                            description=description,                        contact=contact,                        parent_project=None) if subprojects:     dev_project = Project(name=name + ' - Development',                            contact=contact,                            description='Development sub-project for ' + name,                            parent_project=main_project)     doc_project = Project(name=name + ' - Documentation',                           contact=contact,                           description='Documentation sub-project for ' + name,                           parent_project=main_project)     qa_project  = Project(name=name + ' - QA',                           contact=contact,                           description='QA sub-project for ' + name,                           parent_project=main_project) raise tg.redirect('/dashboard')


The post data for this form is passed into the new_project method as parameters. The @validate decorator processes some of the incoming form data. You might remember from before, validators function not only to confirm that incoming data is valid, but also to convert that data into the correct Python data type. This means that contact_id and subprojects will be turned into an int and a Boolean before the main body of the new_project method is executed.

The first thing this method does is look up the person in the database to be the primary contact for the project. The next thing it does is create a new project with the data from the form. The next thing it does is determine whether subprojects ought to be created for this project; if so, it creates three subprojects, one for development, one for documentation, and one for testing and quality assurance.




Rapid Web Applications with TurboGears(c) Using Python to Create Ajax-Powered Sites
Rapid Web Applications with TurboGears: Using Python to Create Ajax-Powered Sites
ISBN: 0132433885
EAN: 2147483647
Year: 2006
Pages: 202

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net