Lines Matching full:controller
118 We'll use explicit routes using URI templates (minus the domains) to match paths. We'll add a little extension that you can use ``{name:regular expression}``, where the named segment must then match that regular expression. The matches will include a "controller" variable, which will be a string like "module_name:function_name". For our examples we'll use a simple blog.
125 app.add_route('/', controller='controllers:index')
127 controller='controllers:archive')
129 controller='controllers:archive')
131 controller='controllers:view')
132 app.add_route('/post', controller='controllers:post')
137 * Something to load the controller
200 Routing: controller loading
220 Now, the ``Router`` class. The class has the ``add_route`` method, and also a ``__call__`` method. That ``__call__`` method makes the Router object itself a WSGI application. So when a request comes in, it looks at ``PATH_INFO`` (also known as ``req.path_info``) and hands off the request to the controller that matches that path.
231 ... def add_route(self, template, controller, **vars):
232 ... if isinstance(controller, basestring):
233 ... controller = load_controller(controller)
235 ... controller,
240 ... for regex, controller, vars in self.routes:
245 ... return controller(environ, start_response)
248 **line 5**: We are going to keep the route options in an ordered list. Each item will be ``(regex, controller, vars)``: ``regex`` is the regular expression object to match against, ``controller`` is the controller to run, and ``vars`` are any extra (constant) variables.
250 **line 8, 9**: We will allow you to call ``add_route`` with a string (that will be imported) or a controller object. We test for a string here, and then import it if necessary.
254 **line 14**: We create a request object. Note we'll only use this request object in this function; if the controller wants a request object it'll have to make on of its own.
262 **line 20**: Then we call the controller as a WSGI application itself. Any fancy framework stuff the controller wants to do, it'll have to do itself.
269 The router just passes the request on to the controller, so the controllers are themselves just WSGI applications. But we'll want to set up something to make those applications friendlier to write.
271 To do that we'll write a `decorator <http://www.ddj.com/web-development/184406073>`_. A decorator is a function that wraps another function. After decoration the function will be a WSGI application, but it will be decorating a function with a signature like ``controller_func(req, **urlvars)``. The controller function will return a response object (which, remember, is a WSGI application on its own).
278 >>> def controller(func):
306 You use this controller like:
310 >>> @controller
321 >>> @controller
331 >>> hello_world.add_route('/', controller=hello)
359 Another Controller
362 There's another pattern that might be interesting to try for a controller. Instead of a function, we can make a class with methods like ``get``, ``post``, etc. The ``urlvars`` will be used to instantiate the class.
436 >>> hello_world.add_route('/', controller=hello)
536 Well, we don't *really* need to factor templating into our framework. After all, you return a string from your controller, and you can figure out on your own how to get a rendered string from a template.
