Posts tagged with django
I explore the integration of a plain Python WSGI app hosted in a Twisted WSGI container, combined with a Server-Sent Events endpoint.
As you may or may not have noticed, I've refreshed my blog. It now runs on Django 1.0 and has a simpler layout.
In the process I've managed to break my feeds, resulting in giving everyone doubly-escaped content. Sorry about that!
If you use a language that's a bit more complex than English (or most western languages, that is), you'll probably have some problems displaying dates that actually don't look like computer-generated.
Django-localdates deals with this problem, and tries to tackle the general problem of internationalizing dates.
django-localdates is a django app that brings local date presentation to django, by providing custom date filters that can use local-flavored format strings.
I spend much time on other people's computers - I'd like to be able to hack for 30 minutes on an idea, but unfortunately, it isn't easy. I have to download and install numerous software packages, like python, django, subversion, an SSH client etc. So I decided to put all that in a flash drive and take it around with me.
There is a neat piece of functionality in Django that will allow you to traverse your object graph by date:
Get next or previous by FOO, where FOO is a Date or DateTime field:
For every DateField and DateTimeField that does not have null=True, the object will have get_next_by_FOO() and get_previous_by_FOO() methods, where FOO is the name of the field. This returns the next and previous object with respect to the date field, raising the appropriate DoesNotExist exception when appropriate...
However, these methods use the default manager, that may be not what one wants.
Congratulations, boulder sprinters!
Or, a tale of reinventing the wheel
Seriously. For web-apps we have tens (maybe hundreds) of frameworks that abstract away the painful details of creating data-based applications.
I mean, using Django, you can whip-up some models, generate the appropriate database schema, play around in admin, maybe use databrowse, generate nice html forms, add a dash of HTML+CSS and you get maybe 80% of the functionality. Then you add your custom views, report generation, a bit of AJAX --if necessary-- and you have a nice data-based web application ready for deployment.
Following up to the part 3 of my series about implementing a multilingual interface for this blog, I now present the things to make the language-magic happen: Middleware and context processors.
I just updated the django code to the latest revision, and a whole host of errors broke up...
I fell into the obligatory problem where non-public items leak out to public feeds. Sorry to everyone, I've updated the feed.
As I wrote in the two previous posts, I wanted the URLs of this site to contain the language the content is in. To do this, I had to write some custom code, including models, managers, middleware and context processors.
Designing URLs for international content can be tricky. I explore the possibilities and use cases, and a clear pattern emerges.
When using the django web administration page to add blog posts, it's nice to be able to preview the post to catch layout glitches, typos and markup issues. The best way to do this is to have a preview page.
From the start, I was interested in making the content posted here available in two languages: Greek and English. This is no small feat, and I thought long and hard on how to make it possible and get it working just the way I like it. So here is a rundown of how internationalization works on this blog.