Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Function/Class '...' was not prepended with 'user_'
I'm currently configuring one of my extension for realurl within Typo3. My aim is to have the categories and subcategories of an article center within the url. But the functionality of lookUpTable does not suffice as I have to observe the nesting of the categories. So I choose userFunc and enter the values as given in the realurl documentation: 'fixedPostVars' => array( 'articlecenter' => array( 'userFunc' => 'EXT:extkey/class.tx_userxyz.php: &tx_realurl_userfunctest->main', ), ), then I clear the cache and it happens... nothing. Only a nice error message is presented: |Function/Class 'E' was not prepended with 'user_'| Seems that my configured values do not really reach the code they should. And of course that's the way it is. After some searching I detect that my configuration is wrong, because realurl is putting all configured values into a nested array wherein every key-value pair is put in as an array that has a numeric indice in the big array. (I hope you can follow my poor english). But my "userFunc" is not set up this way, its numeric indice is userFunc and the array with the key-value pairs is the string EXT:realurl/class.tx_realurl_userfunctest.php:&tx_realurl_userfunctest->main. As realurl runs through this array using foreach it has only "E" … -
Function/Class '...' was not prepended with 'user_'
I'm currently configuring one of my extension for realurl within Typo3. My aim is to have the categories and subcategories of an article center within the url. But the functionality of lookUpTable does not suffice as I have to observe the nesting of the categories. So I choose userFunc and enter the values as given in the realurl documentation: 'fixedPostVars' => array( 'articlecenter' => array( 'userFunc' => 'EXT:extkey/class.tx_userxyz.php: &tx_realurl_userfunctest->main', ), ), then I clear the cache and it happens... nothing. Only a nice error message is presented: |Function/Class 'E' was not prepended with 'user_'| Seems that my configured values do not really reach the code they should. And of course that's the way it is. After some searching I detect that my configuration is wrong, because realurl is putting all configured values into a nested array wherein every key-value pair is put in as an array that has a numeric indice in the big array. (I hope you can follow my poor english). But my "userFunc" is not set up this way, its numeric indice is userFunc and the array with the key-value pairs is the string EXT:realurl/class.tx_realurl_userfunctest.php:&tx_realurl_userfunctest->main. As realurl runs through this array using foreach it has only "E" … -
Function/Class '...' was not prepended with 'user_'
I'm currently configuring one of my extension for realurl within Typo3. My aim is to have the categories and subcategories of an article center within the url. But the functionality of lookUpTable does not suffice as I have to observe the nesting of the categories. So I choose userFunc and enter the values as given in the realurl documentation: 'fixedPostVars' => array( 'articlecenter' => array( 'userFunc' => 'EXT:extkey/class.tx_userxyz.php: &tx_realurl_userfunctest->main', ), ), then I clear the cache and it happens... nothing. Only a nice error message is presented: |Function/Class 'E' was not prepended with 'user_'| Seems that my configured values do not really reach the code they should. And of course that's the way it is. After some searching I detect that my configuration is wrong, because realurl is putting all configured values into a nested array wherein every key-value pair is put in as an array that has a numeric indice in the big array. (I hope you can follow my poor english). But my "userFunc" is not set up this way, its numeric indice is userFunc and the array with the key-value pairs is the string EXT:realurl/class.tx_realurl_userfunctest.php:&tx_realurl_userfunctest->main. As realurl runs through this array using foreach it has only "E" … -
Keeping ContentTypes and Permissions Updated without syncdb
In managing releases to a production django project, I find myself using python manage.py sqlall APPNAME to put the sql needed in a script for any new models, and then writing the ALTER or DROP statements by hand to also go into the sql scripts. One thing that not running syncdb on production leaves out are the creation of the content type and permission records (if using django.contrib.auth and django.contrib.contenttypes). It was recommended to me on #django that I look at each of these apps management.py module to see where they hook into the post_syncdb signal. In doing so I discovered some methods that I could just call from python and keep both my permissions and content types up to date: from django.core.management import setup_environ try: import settings except ImportError: import sys sys.stderr.write("Couldn't find the settings.py module.") sys.exit(1) setup_environ(settings) # Add any missing content types from django.contrib.contenttypes.management \ import create_all_contenttypes create_all_contenttypes() # Add any missing permissions from django.contrib.auth.management import create_permissions from django.db.models import get_apps for app in get_apps(): create_permissions(app, None, 2) Enjoy. -
Keeping ContentTypes and Permissions Updated without syncdb
In managing releases to a production django project, I find myself using python manage.py sqlall APPNAME to put the sql needed in a script for any new models, and then writing the ALTER or DROP statements by hand to also go into the sql scripts. One thing that not running syncdb on production leaves out are the creation of the content type and permission records (if using django.contrib.auth and django.contrib.contenttypes). It was recommended to me on #django that I look at each of these apps management.py module to see where they hook into the post_syncdb signal. In doing so I discovered some methods that I could just call from python and keep both my permissions and content types up to date: from django.core.management import setup_environ try: import settings except ImportError: import sys sys.stderr.write("Couldn't find the settings.py module.") sys.exit(1) setup_environ(settings) # Add any missing content types from django.contrib.contenttypes.management \ import create_all_contenttypes create_all_contenttypes() # Add any missing permissions from django.contrib.auth.management import create_permissions from django.db.models import get_apps for app in get_apps(): create_permissions(app, None, 2) Enjoy. -
Przesiadka na Google App Engine
Dwa wieczory zajęło nam przeportowanie średniej wielkości aplikacji napisanej w Django na Google App Engine (GAE). Możecie ją zobaczyć pod adresem: http://mines.appspot.com Jest to internetowa wersja starej dobrej gry saper. Pierwsza wersja napisana została rok temu, jednak teraz... -
Weblog Updates
My previous blog was my first ever Django application. It worked well, but it was beginning to feel a little clumsy. For example, I had to write posts in HTML. Markdown would be much nicer. I also had separate applications to syndicate links, blog posts, photos, and more. It all felt like a bit of a dogs breakfast. So, inspired by Jacob Kaplan-Moss' jellyroll, and other 'all in one' blog solutions I've seen lately, I've built a somewhat-complete tumblog system in Django. It lets me syndicate links from Magnolia, my blog posts, selected quotes, and soon, photos. Tags are shared across the board, and there is no real separation of content types to the end user. The nice part from my point of view is that I can link to websites I find in my travels, adding commentary, without writing a whole blog post. It can also let me use the neat Magnolia bookmarklets to add links nice and quickly. Lastly, I've published a more minimalist design and removed blog comments. Right now, I'm not one to write provocative blog posts that stir great discussion, so I doubt they'll really be missed. Any comments or thanks can be e-mailed to … -
Weblog Updates
My previous blog was my first ever Django application. It worked well, but it was beginning to feel a little clumsy. For example, I had to write posts in HTML. Markdown would be much nicer. I also had separate applications to syndicate links, blog posts, photos, and more. It all … -
Google App Engine
Dziś w internecie zagrzmiało. Wczoraj Google ogłosiło coś, co nazywa sie Google App Engine. Nie pisał bym o tym tutaj, gdyby nie fakt, że dotyczy to również Django. Google udostępniło platformę do tworzenia aplikacji webowych. Dzięki Google App Engine możemy własne serwisy internetowe... -
Google App Engine: the first look
Yesterday Google announced its new offering: Google App Engine. These are my random notes I did yesterday when I studied the new service.Google didn't go the same way as Amazon with its AWS. The former offers a form of shared hosting (think "distributed WebFaction"), while the latter offers a virtualized environment (think "distributed SliceHost"). So basically we are talking about more high-level approach to web applications, which is easy even for novices. On the other hand AWS is more flexible and more enterprise-y.In order to scale, you have to virtualize. In order to virtualize, some actions should be restricted. Google App Engine provides a sandbox on the language level. Only one language is supported at the moment: Python. And guess what? Django is everywhere! For virtualization reasons only the pure Python is supported and a subset of the Python standard library. You can bundle any pure Python modules with your application. Three third-party libraries are available out-of-the-box: Django 0.96.1, WebOb 0.9, and PyYAML 3.05. But fret not, you can bundle a framework of your choice with your application and run it too, even a custom version of Django — basically anything that supports WSGI. I suspect that other mature Python … -
Google App Engine
Wow! Google just announced Google App Engine which will allow users to host their python applications on their server infrastructure similar to Amazon's EC2 services, but in a more straight-forward manner. The timing is perfect, as I am in the middle of evaluating virtualized hosting for our newspaper websites. The fact that they've started with python and django as the core runtime is huge. That said, all is not perfect. As Eric and I read more into this, there appear to be some serious limitations. The google model library seems simplistic, even by django standards ( don't ask the sqlalchemy folk to weigh in on this one ). Eric has a more complete write-up on this. Pricing is yet to be set. I hope it is reasonable. For my own personal uses, EC2 turned out to be quite expensive compared to the great service I get from SliceHost. I wonder how this will effect all of the smaller hosting companies out there. Free accounts were given to the first 10k users to sign up, and I was pitifully slow in doing so, so I am on the waiting list. Does anyone know if the next wave of accounts will be … -
Google App Engine: the first look
Yesterday Google announced its new offering: Google App Engine. These are my random notes I did yesterday when I studied the new service. Google didn’t go the same way as Amazon with its AWS. The former offers a form of shared hosting (think “distributed WebFaction”), while the latter offers a virtualized environment (think “distributed SliceHost”). So basically we are talking about more high-level approach to web applications, which is easy even for novices. On the other hand AWS is more flexible and more enterprise-y. In order to scale, you have to virtualize. In order to virtualize, some actions should be restricted. Google App Engine provides a sandbox on the language level. Only one language is supported at the moment: Python. And guess what? Django is everywhere! For virtualization reasons only the pure Python is supported and a subset of the Python standard library. You can bundle any pure Python modules with your application. Three third-party libraries are available out-of-the-box: Django 0.96.1, WebOb 0.9, and PyYAML 3.05. But fret not, you can bundle a framework of your choice with your application and run it too, even a custom version of Django — basically anything that supports WSGI. I suspect that other … -
Google Launches App Engine
Google just launched a new platform called App Engine. Basically it allows you to run your web application on Google’s servers using much of their main infrastructure such as BigTable and GFS. The best part is, you write App Engine apps in Python and they include Django out of the box! Mike Arrington has a video of Guido Van [...] -
Django and the Google AppEngine
I’m sure that anyone into Django will either see or hear about this before they catch my blog post, but it’s too neat a story not to write about a comment on. Tonight, Google released AppEngine – an elastic computing … Continue reading → -
Using decorators in Django views to assert the DRY principle
A lot of people finds decorates to be pure magic. I will try to de-mystify some of the magic around them, and show how we can use them to clean up the views in a Django application. I will start by giving a short introduction to decorators and closures and then afterwards show how we can use this in Django to, as the title says, assert the DRY (dont repeat yourself) principle So, what is a decorator? A decorator is a closure. That is, a set of local variables (an evironment) and some code (in this case, a function) to be executed in this environment. A small example of a simple closure: def adder(n): def inner(m): return n + m return inner When a call to adder is made, a new function is returned. This function has one local variable (n) already and takes another one as an argument (m). An example use could be: >>> add_five = adder(5) >>> add_five(37) 42 In Python, it's very popular to say that everything is an object and can be tangled with. This is also the case of functions. When defining a function, all you really do is defining a variable pointing to … -
Internet lifestream with Django
My goal was to archive and display my internet lifestream. My first approach was writing a client for each API of the social networks that I'm in. This turned out to be a complete waste of time and effort. All that I needed after all was a FriendFeed account that would centralize all my feeds. Archiving and displaying your entries with Django is quite simple. First of all, you need to download the Python FriendFeed API client. Then start a new application in your project, lets call it lifestream: ./manage.py startapp lifestream On the settings.py add the lifestream project to the INSTALLED_APPS and a variable to store your FriendFeed username: FRIENDFEED_USERNAME = 'your_username' In the models.py add a model named Entry: from django.db import models class Entry(models.Model): id = models.CharField(max_length=255, primary_key=True) service_id = models.CharField(max_length=50, null=True, blank=True) service_name = models.CharField(max_length=50, null=True, blank=True) service_icon = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) service_profile = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) title = models.CharField(max_length=255, null=True, blank=True) link = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) updated = models.DateTimeField(null=True, blank=True) published = models.DateTimeField(null=True, blank=True) media_title = models.CharField(max_length=255, null=True, blank=True) media_link = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) media_thumbnail = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) created = models.DateTimeField(auto_now_add=True) def __unicode__(self): return self.title class Meta: ordering = … -
Internet lifestream with Django
My goal was to archive and display my internet lifestream. My first approach was writing a client for each API of the social networks that I'm in. This turned out to be a complete waste of time and effort. All that I needed after all was a FriendFeed account that would centralize all my feeds. Archiving and displaying your entries with Django is quite simple. First of all, you need to download the Python FriendFeed API client. Then start a new application in your project, lets call it lifestream: ./manage.py startapp lifestream On the settings.py add the lifestream project to the INSTALLED_APPS and a variable to store your FriendFeed username: FRIENDFEED_USERNAME = 'your_username' In the models.py add a model named Entry: from django.db import models class Entry(models.Model): id = models.CharField(max_length=255, primary_key=True) service_id = models.CharField(max_length=50, null=True, blank=True) service_name = models.CharField(max_length=50, null=True, blank=True) service_icon = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) service_profile = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) title = models.CharField(max_length=255, null=True, blank=True) link = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) updated = models.DateTimeField(null=True, blank=True) published = models.DateTimeField(null=True, blank=True) media_title = models.CharField(max_length=255, null=True, blank=True) media_link = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) media_thumbnail = models.URLField(max_length=255, verify_exists=False, null=True, blank=True) created = models.DateTimeField(auto_now_add=True) def __unicode__(self): return self.title class Meta: ordering = … -
It's free; stop whining
Soma FM is arguably the best free online radio service. As of this writing they have 13 channels, most, like their most popular Groove Salad, are electronic/ambient, though Indie Pop Rocks is also immensely popular. Despite being 100% free, people still complain about the service. -
XML-RPC dispatching through Django test client
Django has a cleverly designed test client that creates a WSGIRequest and routes it through your views without the need of a web server. Furthermore it works on a temporary test database, thus any errors won't have any effect on your live database. I'm currently working on an application written using Django. This application, amongst other features, has an XML-RPC interface. The tests for this interface was being done by spawning a local web server and carrying out the tests over the wire. However, it would be nice to exploit the Django test framework. The solution is amazingly simple. I wrote a TestTransport class for xmlrpclib: import cStringIO from xmlrpclib import Transport from django.test.client import Client class TestTransport(Transport): """ Handles connections to XML-RPC server through Django test client.""" def __init__(self, *args, **kwargs): self.client = Client() def request(self, host, handler, request_body, verbose=0): self.verbose = verbose response = self.client.post(handler, request_body, content_type="text/xml") res = cStringIO.StringIO(response.content) res.seek(0) return self.parse_response(res) In my tests where I use the XML-RPC interface I initialize the ServerProxy object with: server = ServerProxy('http://localhost/xmlrpc/', transport=TestTransport()) That's about it. Now calls trough the server object will be handled by the Django test client. In my case I had a decorator around the … -
XML-RPC dispatching through Django test client
Django has a cleverly designed test client that creates a WSGIRequest and routes it through your views without the need of a web server. Furthermore it works on a temporary test database, thus any errors won't have any effect on your live database. I'm currently working on an application written using Django. This application, amongst other features, has an XML-RPC interface. The tests for this interface was being done by spawning a local web server and carrying out the tests over the wire. However, it would be nice to exploit the Django test framework. The solution is amazingly simple. I wrote a TestTransport class for xmlrpclib: import cStringIO from xmlrpclib import Transport from django.test.client import Client class TestTransport(Transport): """ Handles connections to XML-RPC server through Django test client.""" def __init__(self, *args, **kwargs): self.client = Client() def request(self, host, handler, request_body, verbose=0): self.verbose = verbose response = self.client.post(handler, request_body, content_type="text/xml") res = cStringIO.StringIO(response.content) res.seek(0) return self.parse_response(res) In my tests where I use the XML-RPC interface I initialize the ServerProxy object with: server = ServerProxy("http://localhost/xmlrpc/", transport=TestTransport()) That's about it. Now calls trough the server object will be handled by the Django test client. In my case I had a decorator around the … -
Django request logging with rsyslog
In my original post about logging Django requests, I had only tried my code with syslog-ng. It works fine with rsyslog too. -
Presenting truly international dates in Django
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. The main issue is, if you want your application to be truly international, you have to find a translator that will translate your templates, messages, emails and everything else that a user might see. However, translating dates isn't that straightforward. The easiest example is US vs British date format. US citizens write the month first, while the British write the month after the date. So, if you have a template that uses now "d F Y", it will look good for a British person, but not for an US person. A Russian would be appaled, because Март isn't the same as марта! django-localdates tries to overcome all this by defining translatable date formats. Every language has a "formal" way to display dates, a short way, a numeric way and so on. So if we could just specify "This date should be formatted to be short" or "This day is the full deal", and have … -
FormWizard: multiple-step forms in Django
Have you ever had to implement a multiple-step form? It can be a headache trying to keep track of all the data, especially while validating each form in the process. Django’s new FormWizard class makes it wickedly easy. -
eSteak - hot MooTools slices
By now there are many javascript frameworks available that make programming easy and encapsulate new and cool functionalities. Surely every framework has its advantages and disadvantages but in my opinion you can't switch between all of them - you have to deceide in favour of one. In my case I have chosen Mootools, as you may have already seen here... A friend of mine and also a co-worker, Grundi, has created a site that answers to the beautiful name of "eSteak" that unites the different scripts for Mootools on a central place, with rating, Mootools dependency listing and so on. The whole thing is user generated content, so its up to all the Mootools developers and even to you to upload scripts and support it! Because the problem with Mootools is that there are really cool scripts out there, but you first have to find them. I hope that eSteak will be filled with a lot of scripts and that it will develop to the central place for Mootools friends and enthusiasts. Update (somewhen in 2013): unfortunately eSteak was taken to the grave in 2010 - check this blog post for more information: http://blog.aplusmedia.de/2010/10/19/esteak-net-end-of-life-announcement/ -
eSteak - hot MooTools slices
By now there are many javascript frameworks available that make programming easy and encapsulate new and cool functionalities. Surely every framework has its advantages and disadvantages but in my opinion you can't switch between all of them - you have to deceide in favour of one. In my case I have chosen Mootools, as you may have already seen here... A friend of mine and also a co-worker, Grundi, has created a site that answers to the beautiful name of "eSteak" that unites the different scripts for Mootools on a central place, with rating, Mootools dependency listing and so on. The whole thing is user generated content, so its up to all the Mootools developers and even to you to upload scripts and support it! Because the problem with Mootools is that there are really cool scripts out there, but you first have to find them. I hope that eSteak will be filled with a lot of scripts and that it will develop to the central place for Mootools friends and enthusiasts. Update (somewhen in 2013): unfortunately eSteak was taken to the grave in 2010 - check this blog post for more information: http://blog.aplusmedia.de/2010/10/19/esteak-net-end-of-life-announcement/