Skip to content
Find file
Latest commit 953eb33 Jul 4, 2009 Simon Willison Very basic template support - after umming and aahing for months, her…
…e's the simplest thing that could possibly work. See for an example.
Failed to load latest commit information.
djng Very basic template support - after umming and aahing for months, her… Jul 4, 2009
LICENSE.txt Started to play around with the concept of services May 9, 2009 Added example of form validation using the Django forms library, had … May 12, 2009 Figured out what hello world should look like in djng, then implement… May 11, 2009 Added djng.middleware.GZip and example of applying that middleware to… May 18, 2009 Example showing how staticmethods can be used to reduce chance of acc… May 12, 2009 De-emphasized the example_app for services that doesn't do anything i… May 11, 2009 Very basic template support - after umming and aahing for months, her… Jul 4, 2009 ErrorWrapper: send correct status code back to browser May 22, 2009
planned_services.txt URL reversing should be a service May 14, 2009
readme.txt ErrorWrapper: send correct status code back to browser May 21, 2009
services_api_ideas.txt Added a May 22, 2009


(pronounced "djing", with a mostly-silent "d")

Blog entry:
Mailing list:

djng is a micro-framework that depends on a macro-framework (Django).

My definition of a micro-framework: something that lets you create an entire
Python web application in a single module:

    import djng
    def index(request):
        return djng.Response('Hello, world')
    if __name__ == '__main__':
        djng.serve(index, '', 8888)

Or if you want hello and goodbye URLs, and a custom 404 page:

    import djng

    app = djng.ErrorWrapper(
            (r'^hello$', lambda request: djng.Response('Hello, world')),
            (r'^goodbye$', lambda request: djng.Response('Goodbye, world')),
        custom_404 = lambda request: djng.Response('404 error', status=404),
        custom_500 = lambda request: djng.Response('500 error', status=500)
    if __name__ == '__main__':
        djng.serve(app, '', 8888)

Under the hood, djng will re-use large amounts of functionality from Django,
while re-imagining various aspects of the framework. A djng request object is
a Django HttpRequest object; a djng response object is a Django HttpResponse.
Django's template language and ORM will be available. Ideally, Django code
will run almost entirely unmodified under djng, and vice versa.

Services, not Settings

I dislike Django's file - I often find I want to reconfigure
settings at run-time, and I'm not comfortable with having arbitrary settings
for so many different aspects of the framework.

djng experiments with /services/ in place of settings. Services are bits of
shared functionality that djng makes available to applications - for example,
caching, templating, ORM-ing and mail-sending.

Most of the stuff that Django sets up in will in djng be set up by
configuring services. These services will be designed to be reconfigured at
run-time, using a mechanism similar to Django middleware.

Some things that live in that really don't belong there -
middleware for example. These will generally be constructed by composing
together a djng application in code.

I'm still figuring out how the syntax for services should work.
Something went wrong with that request. Please try again.