Building Single-page web-applications with Django, Twisted and TxWebsocket

Talk by Jeroen van Veen (Goldmund, Wyldebeast & Wunderliebe, GWW).

Websockets give you a persistent TCP connection from a browser to the server. So: you don't need to do a request every time. The connection is there. You need to decide what to send over that connection. This does not need to be HTTP.

With javascript you can upgrade to a persistent connection. The protocol for the handshake used here is changing but getting more stable. Google for Hybi-16. Both utf-8 encoded data and binary data are supported. You have low latency: no headers need to be sent every time, the connection does not need to be setup for each request. So it has a very small foot print. The preferred way of serialization, for me at least, is with JSON.

There is support for this in Python: TxWebsocket (my preferred library, based on Twisted), Autobahn WS, Gevent-websocket. Supported in browsers: Chrome, Firefox, Opera, Safari, IE 10. As browser fallback you could use Flash Websocket.

When buildout a web application, you have to decide whether to build this multi-page or single-page. Multi-page is of course what most websites are using. For a single-page approach, (almost) everything is done on one page. You bootstrap a page, that sets up the websocket connection using the handshake. In this handshake the sessionid cookie from Django can be reused so you can authenticate.

I want to mimic Django URL routing on the server side. And on the client side too, really, using javascript. I use XRegexp for named group support, which helps here. When clicking on a link, you do not want to end up in a fresh page, but want to stay on the same page. But you can change the URL of the navigation bar anyway with javascript. It starts acting more like a multi-page website then, but can still remain single-page. This is usable with the HTML5 history API, better than for example adding hashes to the url. Using this, you can build a website where you can edit the same document with multiple persons simultaneously.

Django WS arranges the authentication during the handshake with the session cookie. It handles a client transport pool, event subscription, websocket URL-routing protocol; Twisted MultiFile, runws, autoreload; BSD license. It is in development. Modules: core, misc, blog, wiki. It is used in a project now for narrow casting, letting messages appear on screens, possibly for a longer period.

There are some challenges. Cleanup the design and architecture. A usable pluggable reference CMS. Proper documentation. Community. SEO: a web crawler will not index much, as only the contents of the bootstrap page are indexed.

The Django WS Code is on github: https://github.com/phrearch/django-ws-core Find me on Twitter: @jeroen_van_veen.

Audience: look at Tornado, it does something similar.

Document automation (Office) using Django

Talk by Henk Vos: http://www.rapasso.eu

You want to generate for example a Word document by pushing a button on your website and have this document contain some information that comes out of your database. You could install MS Office on your server. But we have Linux, and it is not available there. You could use a different box. Or maybe Google Docs, or the Pyuno bridge to OpenOffice. There is also python-docx.

But really, such a Word document is just an archive with some xml files. So we can use the Django template engine. Put some normal {{Django variables}} literally in your Word document. Extract the important file from the archive, run the Django template engine over it, save it, zip it up again, and let your web server serve it in a request.

DjangoCon Europe

Talk by Reinout van Rees (http://reinout.vanrees.org/)

This year's DjangoCon Europe was in Zürich, inside a stadium, a few weeks ago.

There were several talks about the real-time web. Tricky is that you can end up with two parallel MVC stacks, one in the Django backend and one in the Javascript frontend. Putting a caching server in front to speed things up will not work with web sockets. Idea is at least to always use an API.

Databases. Not everything fits in one kind of database. Files are better handled on the file system. There were tips for Postgres. You could use a big box and store everything. The NoSQL support in Django core is not done yet.

A few talks about diversity. Involving women in the community. Hard discussion. Stereotypes everywhere.

Healthy web apps. dogslow: for tracebacks.

CSS. http://gluecss.com for sprite compression. Preprocessors: hurray!

Security. Login should be done using SSL (so https). Try a restore of your backups some time, otherwise you might as well not make any backups, as you do not know if it actually helps you. django-admin-sso for giving easier access to admins for several servers.

Heroku. It's a 'cloud unix'. Focused apps, one thing. You can only use an API to communicate with the outside world. Plus documentation. They have 2-3 person teams. That was the ideal size for them. Quality comes from solid engineering, so you need time, not deadlines.

Various bits. You need to work with timezone-aware datetimes. Flask micro framework. Django core moved to github, which turned out very well.

See summaries on my website: http://reinout.vanrees.org/ There are videos online too. Check the Heroku talk and the keynote about internationalization.

Rethinking the Django-CMS landscape

Talk by Diederik van der Boor (Edoburu).

Why does everyone create there own CMS (in Django)?

Do one thing and do it well. Tight focus versus feature creep. Don;t be afraid of multiple apps in your website, separate them out. Write for flexibility and distribution.

There are various Django CMSes. You've got Django CMS, FeinCMS, Fiber, Ella, Merengue, Philo and more. Big outside contenders are Wordpress (easy to setup, but plugin hell) and Umbraco (customized UI layouts, customised page node types).

For page contents and a page tree you can use the django-fluent-pages package. That might be the only CMS-like functionality you need in your application, instead of a full blown CMS. You can use plugins, like code highlighting, MarkDown, or create your own.

If you are going to create a blog you could do it as one application, but it should really be several separate applications. Do one thing and do it well: the django-fluent-comments package.

How about user authentication, social media auth, RSS feeds for comments, e-mail subscriptions, spam protection. Those should also be separate packages. Currently, most blog applications have all or some of these thrown together.

So mostly: separate your packages.

There is a balance to strike: a too monolithic one-package approach, versus lots of packages that need lots of glue code.

See the code at https://github.com/edoburu Find me on Twitter: @vdboor and @edoburu.

Audience: a danger is that your application might work today and is broken tomorrow when someone uploads a new release on PyPI that has backwards incompatible changes. You need to keep an eye on that. Freeze your dependencies in production.

TND Dataview and Metaclass Magic in Python

Talk by Maarten ter Horst from Top Notch Development.

Python metaclasses are ideal for frameworks and abstract classes, code that you want to reuse. A metaclass is a class that handles the creation of other classes. So an instance of a metaclass is a class. Normal classes inherit from object but meta classes inherit from type. It creates a new class based on your class. So basically you can use this to have a different base class instead of object and override some basic behaviour. You can for example check if a newly created class conforms to an interface.

We use it to inspect the class definition and add a urls method that lists all other methods that return an HTTP object.

Google 'IBM Python metaclass' for a good tutorial on metaclass programming. The presentation is available soon on Top Notch Development.