Response¶

class Response(content='', status_code=STATUS.OK, content_type='text/html')¶

encoding¶

status_message¶

headers¶

A dict of HTTP headers

cookies¶

A SimpleCookie container for resposne cookies.

add_cookie(key, value, **kwargs)¶

Add a cookie to the response.

If only key and value are passed, then dict access to self.cookies is used. Otherwise, a Morsel is instanciated, and the key, value and kwargs passed to its set method. Then it’s added to the cookies container.

status¶

A helper to return the status code and message as a single string.

STATUS_CODES¶

A tuple of two-tuples, each of (status code, status message)

STATUS¶

An OrderedDict sub-class constructed from STATUS_CODES.

Additionally, the status codes can be accessed by name.

For example:

>>> STATUS.OK
200

>>> STATUS[200]
'OK'

urls_dispather.register¶

You can dynamically add patterns to a urls_dispatcher by calling the instances register method:

urls = url_dispatcher(....)

urls.register(pattern, view)

Additionally, you can decorate your views to add them to the url_dispatcher.

urls = url_dispatcher()

@urls.register(pattern)
def view(request...):

inner_patterns = url_dispatcher(
    ...
)

root_view = url_dispatcher(
    ...
    (r'^/inner/', inner_patterns),
)

class my_url_dispatcher(url_dispatcher):
    def handle_not_found(self, request):
        return http.NotFound("Could not find a page for %s" % request.path)

Functional¶

def get_foo(self):
    ...

foo = buffered_property(get_foo, name='foo')

Middleware¶

The need for middleware is obviated by the fact everything is a view. If you want to hook in something to do work before matching a view, before calling a view, or on the way out, you can just wrap that view in your own view.

This was a pattern proposed in Django also, to help disambiguate which middleware methods are called when, but it has not been included yet as it is too much of a backward-incompatible burden.

Further to this approach, it now becomes much simpler to selectively implement middleware, as you can wrap only the views or dispatcher paths you choose.

URL Patterns¶

There is a Django-style URL dispatcher view included in views/urls.py

There is currently no support for named url patterns or reversing urls.

Hello World!¶

import antfarm

def index(request):
    return antfarm.Response('Hello World!')

application = antfarm.App(root_view=index)

Simple URL routing¶

import antfarm
from antfarm.views.urls import url_dispatcher

def index(request):
    return antfarm.Response('Index')

def detail(request, user_pk):
    return antfarm.Response('You asked for %s' % user_pk)

application = antfarm.App(
    root_view = url_dispatcher(
        (r'^/$', index),
        (r'^/details/(?P<user_pk>\d+)/$', detail),
    )
)

Middleware¶

It’s easy to write “Middleware” style views, which do some work before or after other views.

class middleware(object):
    def __init__(self, view):
        self.view

    def __call__(self, request, *args, **kwargs):
        # Work before
        try:
            return self.view(request, *args, **kwargs)
        except ...:
            # Catch errors
        finally:
            # Work after _always_


 application = App(root_view = middleware(normalview))

Selective Middleware¶

An idea which resurfaces frequently in the Django community is one of applying middleware to a sub-set of the URL tree. The only existing solution is to apply a decorator to all the views [tedious and error prone] or to complicate the middleware with ways to denote what it is to apply to.

In Antfarm, this problem is trivially solved, since middleware are just views which wrap views.

A simple example is making some URLs password protected, but not others.

private_urls = url_dispatcher(
    (r'^$', views.user_list),
    (r'^(?P<user_id>\d+)/$', views.user_detail),
)

root_urls = url_dispatcher(
    (r'^/$', views.index),
    (r'^/login/$', views.login),
    (r'^/users/', login_required(private_urls)),
)

Running tests¶

A test suite using the standard library’s unittest package exists in the tests directory of the git repository, it can be run from the root of the repository via:

python tests

To run only the tests in a specific file, you may do:

python tests/<filename>.py

To generate a coverage report for the test suite:

coverage run tests/__main__.py

Once the coverage data is generated, you can report on it using your preferred output method.

Writing tests¶

New tests should either be added to the appropriate test file, if it already exists, or to a new file in the tests directory, whose name is prefixed with test_:

tests/test_<thing_to_test>.py

Test classes should be written such that they subclass unittest.TestCase and are named with a Test suffix:

from unittest import TestCase

class ThingTest(TestCase):
    pass

Individual test methods should be named and numbered like so:

class ThingTest(TestCase):
    def test_001_function_description():
        pass

    def test_002_another_function_description():
        pass

Finally, to allow individual test files to be without the rest of the suite, the file should end with the following if statement:

from unittest import main

if __name__ == '__main__':
    main()