Popular recipes tagged "dispatcher"

Python: A event/signal dispatcher (Python)

2013-07-29T05:34:24-07:00

Python recipe 578307 by Esteban Castro Borsani (dispatcher, events, oop, python, signals).

This is a thread-safe dispatcher.

Fast and elegant switch/case-like dispatch (Python)

2011-09-02T01:49:40-07:00

Python recipe 577864 by Jan Kaliszewski (case, decorator, dispatcher, performance, switch). Revision 4.

My approach to that common issue focuses on efficiency and elegant, declarative style of definition. That's why:

The way switches work is based on unwrapped defaultdict/list lookup.
The way you define switches is based on classes and easy-to-use decorators (note that you can use subclassing in a flexible way -- without any negative impact on efficiency!).
Its use cases focus on a-lot-of-keys situations and it does not cover the fall-through feature (though you can reach its semantics if you really need that -- by calling class methods...).

A powerful yet simple switch-like dispatch system for Python (Python)

2010-12-21T04:38:48-08:00

Python recipe 577507 by Michael Kent (dispatcher, switch). Revision 2.

This module provides a powerful 'switch'-like dispatcher system, using decorators to give a syntax somewhat like that of the switch statement in C. Values for switch cases can be anything comparable via '==', a string for use on the left-hand side of the 'in' operator, or a regular expression. Iterables of these types can also be used.

Simple event dispatcher (Python)

2010-10-19T21:18:45-07:00

Python recipe 577432 by Daniele Esposti (dispatcher, event).

An example of a simple event dispatcher mini-framework

Method-based URL dispatcher for the Tornado web server (Python)

2009-11-20T11:51:47-08:00

Python recipe 576958 by Dan McDougall (dispatcher, shortcuts, subclass, tornado, url, web). Revision 5.

The MethodDispatcher is a subclass of tornado.web.RequestHandler that will use the methods contained in subclasses of MethodDispatcher to handle requests. In other words, instead of having to make a new RequestHandler class for every URL in your application you can subclass MethodDispatcher and use the methods contained therein as your URLs.

The MethodDispatcher also adds the convenience of automatically passing arguments to your class methods. So there is no need to use Tornado's get_argument() method.

Example

To demonstrate the advantages of using MethodDispatcher I'll present a standard Tornado app with multiple URLs and re-write it using MethodDispatcher...

The standard Tornado way

class Foo(tornado.web.RequestHandler):
    def get(self):
        self.write('foo')

class Bar(tornado.web.RequestHandler):
    def get(self):
        self.write('bar')

class SimonSays(tornado.web.RequestHandler):
    def get(self):
        say = self.get_argument("say")
        self.write('Simon says, %s' % `say`)

application = tornado.web.Application([
    (r"/foo", Foo),
    (r"/bar", Bar),
    (r"/simonsays", SimonSays),
])

The MethodDispatcher way

class FooBar(MethodDispatcher):
    def foo(self):
        self.write("foo")

    def bar(self):
        self.write("bar")

    def simonsays(self, say):
        self.write("Simon Says, %s" % `say`)

application = tornado.web.Application([
    (r"/.*", FooBar)
])

Notes

As you can see from the above example, using the MethodDispatcher can significantly reduce the complexity of Tornado applications. Here's some other things to keep in mind when using the MethodDispatcher:

MethodDispatcher will ignore any methods that begin with an underscore (_). This prevents builtins and private methods from being exposed to the web.
The '/' path is special: It always maps to self.index().
MethodDispatcher does not require that your methods distinquish between GET and POST requests. Whether a GET or POST is performed the matching method will be called with any passed arguments or POSTed data. Because of the way this works you should not use get() and post() in your MethodDispatcher subclasses unless you want to override this functionality.
When an argument is passed with a single value (/simonsays?say=hello) the value passed to the argument will be de-listed. In other words, it will be passed to your method like so: {'say': 'hello'}. This overrides the default Tornado behavior which would return the value as a list: {'say': ['hello']}. If more than one value is passed MethodDispatcher will use the default behavior.