Skip to content
alabid edited this page Aug 7, 2012 · 22 revisions

Controllers

According to the MVC specification which whirlwind is based upon, the Controller should handle the business logic. The Controller receives and responds to requests from the client. The user's requests for pages are routed to some subclass of the python class BaseRequest using the @route decorator.

Here's an example implementation of a controller that handles "static page" requests:

from whirlwind.core.request import BaseRequest                                                             
from whirlwind.db.mongo import Mongo                                                                       
from tornado.web import authenticated                                                                      
from whirlwind.view.decorators import route                                                                
                                                                                                        
@route('/')                                                                                                
class IndexHandler(BaseRequest):                                                                           
  def get(self):                                                                                         
    #template context variables go in here                                                             
    template_values = {}                                                                               
    
    # you can do some database manipulation here
    # or not do anything at all
   
    # render the template defined in application/views/site/index.html                                                                                             
    self.render_template('/site/index.html',**template_values)    

The above controller code just handles rendering the root page. This page can be in its own file: sites_controller.py.

We suggest that the Request Handlers (which are subclasses of BaseRequests) be categorized according to functionality. In other words, Request Handlers that handle static requests (that aren't related to any other indepth functions) can be placed together in sites_controller.py in the controllers folder. Handlers that handle requests to login and logout of the application can be placed in an accounts_controller.py. And so on...

In addition, each handler you define should have a 'get' or 'post' method or both. This conforms to the REST specification. For more information on the methods you can define in the subclass of BaseRequest, refer to the tornado RequestHandler documentation.

BaseRequest

The BaseRequest class is defined in the whirlwind python source. It's a subclass of the RequestHandler class that's part of the tornado python web server.

##Methods of BaseRequest

The BaseRequest class has several methods that are useful in rendering template file and template strings.

The methods explicated below can be invoked in a subclass of BaseRequest like this:

class IndexHandler(BaseRequest):                                                                           
    def get(self):
        self.baseRequestMethod(params,...)

where baseRequestMethod is the method of the BaseRequest to invoke.


Method : template_exists

Params : template_name - name of template

Returns : true if the template defined at template_name exists. Else returns false.

Example Use

if self.template_exists('/site/index.html'):
    print "yes! template exists there"

Method : render_string

Params : *template_name - name of template

  • **kwargs - dictionary of options to pass to view. For example, kwargs['me']="hi" would make the variable me available to the view.

Returns : String that's the result of pre-processing the template at template_name against the mako template syntax rules.

Alias : render_to_string

Example Use

str_to_render = self.render_to_string('/site/index.html')

# do some cool stuff with str_to_render

self.write(str_to_render)

Method : render_template

Params :

  • template_name - name of template to render

  • **kwargs - dictionary of options to pass to view. Same as in render_string

Return : None.

Note: This method is blocking and should be put at the bottom of the calling method.

Example Use

self.render_template('/site/index.html') # The last line of the BaseRequest handler

Method : get_nested_argument

Params : prefix - the prefix of the nested arguments to retrieve

Return : a dictionary of parameters. The keys will be the remaining part of the parameter keys (excluding the prefixes).

Example Use

suppose what's sent is:

p[first], p[second], p[third]

We suggest that the controllers Request Handlers be classified according to

@threaded

@authenticated

Rendering Templates

The controller sometimes handles requests by rendering a template or by just writing out JSON or plain HTML to the client Since the controller handles client requests, it

Clone this wiki locally