Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Changeset 7967: NFA Branch Merged into Trunk
I and a host of other folks have been waiting anxiously for this merge for a while now. Excited to see it happen tonight. Good job, Brian Rosner et al. -
Duże zmiany w django
Django idzie dużymi krokami do przodu. Coraz większe zmiany zachodzą w głównym repozytorium. Niedawno pojawił się tam patch o nazwie Large streaming uploads, czyli możliwość użycia Django do wysyłania bardzo dużych plików, które bezpośrednio, podczas wysyłania, mogą być zapisywane... -
GitHub Enables Markdown Documentation
I have been desiring to have the documentation that I write for my various projects on GitHub render to HTML when using a .markdown extension, just like they support doing for special files like README.markdown. At first, I thought they'd eventually get around to it and that is the best I could hope for as surely they are too busy to respond to a non-paying customer like me. Then I learned they the used the Lighthouse ticket system to manage their project and took public submissions for features. Before logging a feature request I did some searching and found a ticket already out there requesting exactly this same feature that I wanted. So I just added my own comments to the ticket to give it a +1. After a little back and forth I learned it was implemented tonight (just a week after my first comment). Good to see such responsive development. An example of this feature can be found in my django-aws project which is simple app to provide some template tags to provide Amazon Web Services information a la boto. -
GitHub Enables Markdown Documentation
I have been desiring to have the documentation that I write for my various projects on GitHub render to HTML when using a .markdown extension, just like they support doing for special files like README.markdown. At first, I thought they'd eventually get around to it and that is the best I could hope for as surely they are too busy to respond to a non-paying customer like me. Then I learned they the used the Lighthouse ticket system to manage their project and took public submissions for features. Before logging a feature request I did some searching and found a ticket already out there requesting exactly this same feature that I wanted. So I just added my own comments to the ticket to give it a +1. After a little back and forth I learned it was implemented tonight (just a week after my first comment). Good to see such responsive development. An example of this feature can be found in my django-aws project which is simple app to provide some template tags to provide Amazon Web Services information a la boto. -
Django auto-translation of field values
What’s really nice in Django is the gettext implementation and the _ convention. But when running django-admin.py makemessages we’re not generating any translations for dynamic values such as field values. So let’s say that we have a model and we’d … Continue reading → -
First wapi release
Wapi is somewhat 80% finished, so I think it's ready for the first release. The zipfile includes the wapi code as well as some examples taken from byNotes. You'll notice there are authentication methods for Basic, Digest and OAuth. However, only the former is usable for now, since the other two depend on Django applications which are't ready for release (but are likely to be ready before this week ends). If you try this, leave some feedback in a comment ;). I advise you to not use this code into production yet, since the API may change in the near future. -
Tip: Extending Django flatpages
I did a Google search and since nothing came up, I’m writing this little tip on creating your own CMS by extending Django’s flatpages. What’s good about flatpages is that they’re included in Django and has some basic code to … Continue reading → -
Wapi release coming next week
Wapi, the django application for publishing web apis, will be ready next week. These are the features implemented for now: Exposing ResT apis with transparent serialization (i.e. your code just returns a serialization preset, wapi formats it for you). API-as-class approach: Every function defined inside a class translates to an API method. Then, the class is plugged inside an exposer and it takes care of receiving the parameters and passing them to your function. Authentication middleware: The exposers take an optional parameter which let's your API authenticate users. Currently, there are authentication methods for HTTP Basic (against django.contrib.user database or custom auth function), HTTP Digest (custom auth with helpers for preparing a django.contrib.user database for digest auth) and OAuth (with extensions for token duration and token attributes, all customizable). The newserializers API is included inside wapi as wapi.serializers. Decorators for marking functions as login-required, read-only, write-only... And these are the features planned for the future: SOAP exposer Automatic WDSL generation What do you think about it? Do you miss something which could be useful for exposing Web APIs? -
Using IntelliJ for Django Development
About a year ago I’ve switched over to IntelliJ as my primary Java IDE. When I began to dabble a bit in Django a few days ago, I realized that IntelliJ had me spoiled when it comes to Editor Features – especially when working with Javascript and HTML files. Notepad++ – although a great text editor on its own right – simply didn’t cut it for me for web development. When I tried opening my Django files in IntelliJ I had to realize that IntelliJ needs a project context for opening a file. Even for a simple html file. Fortunately the solution was pretty straight forward. Navigate to your Django project root directory and create a new file .project. Some of you have guessed it: we are pretending to be Eclipse. Open the file in a text editor and paste the following snipped into it: <?xml version=”1.0″ encoding=”UTF-8″?> <projectDescription> <name>myproject</name> <comment></comment> <projects></projects> </projectDescription> Edit the <name> tag value and change it to your liking. Now it’s time to launch IntelliJ. Select File -> New Project. Select Import project from external model and click Next. Select Eclipse (should be the default) and click Next. Now enter the path to your Django … -
EuroPython 2008, day 3
For me, the main theme for the third and last day of the conference was Django. Day started with a session by Honza Král about Django newforms admin, which gave me a pretty good idea what I have to do in preparing for the migration to the new admin interface. Later on the day I had many interesting discussions about varions Django-related things, including ideas about having something like Django release party here in Europe, too. <a href="http://www.flickr.com/photos/uninen/2655794578/" title="We had time to visit the Vilnius TV tower"><img src="http://farm4.static.flickr.com/3183/2655794578_fcd0aba681_m.jpg" width="180" height="240" alt="At Vilnius TV Tower" align="right" /></a>Turns out there are quite a lot Djangonauts here in EuroPython, we just arent organized very well so most of us don't know about each other. Lively after-conference discussions about career choises, Web Design and working with Django in general were definitely the high point of the conference so far. A couple of hour later on the evening, decisions about quiet evening at the Sky Bar (at the 22nd floor of the conference hotel) were forgotten and, again, we headed for the old town. This time we ended up in some night club and, well, yeah, we had a great time :) -
Ordering Edit Inlines
In my continued experimentation with the newforms-admin branch of Django, I wanted to figure out how to order fields of an inline. Looking at the documentation for inlines I saw there was not an ordering field. I had thought that there was but it turns out I was just mistaken in the object hierarchy. InlineModelAdmin inherits from BaseModelAdmin the same as ModelAdmin -- I was thinking that InlineModelAdmin inherited from ModelAdmin. Therefore, I had to determine a way to accomplish this via some spelunking through the code. At first, I thought I'd just create my own template by inheriting or copying the tabular.html template. After looking at it, I determined that I didn't want to figure out how to do a regroup on inline_admin_formset or if even that was the proper way to try to order things in that template. After a few minutes in the code I realized that I could just subclass BaseInlineFormset and specify the fields that I wanted to order by (in this example I will use start_time and end_time: from django.contrib import admin from django.newforms.models import BaseInlineFormset class MyOrderedFormset(BaseInlineFormset): def get_queryset(self): qs = super(SessionInlineFormset, self).get_queryset() return qs.order_by('start_time', 'end_time') class MyOrderedInline(admin.TabularInline): model = MyModel extra = … -
Ordering Edit Inlines
In my continued experimentation with the newforms-admin branch of Django, I wanted to figure out how to order fields of an inline. Looking at the documentation for inlines I saw there was not an ordering field. I had thought that there was but it turns out I was just mistaken in the object hierarchy. InlineModelAdmin inherits from BaseModelAdmin the same as ModelAdmin -- I was thinking that InlineModelAdmin inherited from ModelAdmin. Therefore, I had to determine a way to accomplish this via some spelunking through the code. At first, I thought I'd just create my own template by inheriting or copying the tabular.html template. After looking at it, I determined that I didn't want to figure out how to do a regroup on inline_admin_formset or if even that was the proper way to try to order things in that template. After a few minutes in the code I realized that I could just subclass BaseInlineFormset and specify the fields that I wanted to order by (in this example I will use start_time and end_time: from django.contrib import admin from django.newforms.models import BaseInlineFormset class MyOrderedFormset(BaseInlineFormset): def get_queryset(self): qs = super(SessionInlineFormset, self).get_queryset() return qs.order_by('start_time', 'end_time') class MyOrderedInline(admin.TabularInline): model = MyModel extra = … -
EuroPython 2008, day 2
I skipped most of the sessions for the day as they didn't seem even remotely interesting to me. But, the ones I did attend where really good. [Last nights partying](http://www.flickr.com/photos/uninen/2647190250/) kept me pretty much in bed for better part of the morning. **Descriptor tutorial** by Raymond D. Hettinger was very good and I think it was actually the first conference tutorial ever that actually teached me something about programming and Python in general. There was quite a bit testing-related material on the **Lightning talks**. One thing I wrote down on my notes was the phrase "Given enough tests, all bugs are shallow" (originally from Linus Torvalds in a form "Given enough eyeballs, all bugs are shallow"). The **keynote talk** for the day was something that absolutely blew my mind. Hans Rosling talked about [Gapminder](http://www.gapminder.org/) and how statstical data and databases should be free. First thing that crossed my mind when listening to him was that "I wonder if Adrian Holovaty has ever talked to this guy -- they'd have much to talk about". If you havent heard about Gapminder or Hans Rosling before, you should definitely [see his talk on last years TED conference](http://www.ted.com/index.php/talks/hans_rosling_shows_the_best_stats_you_ve_ever_seen.html). In Django-terms, thats some cool shit … -
Legibilidade e reaproveitamento de código na "URLConf"
É comum nas configurações de URL (URLconf) [1] do Django, patterns como este abaixo: urlpatterns = patterns( 'django.views.generic.date_based', (r'^(?P<year>\d{4})/(?P<month>[0-9]{2})/(?P<day>\d{1,2})/(?P<slug>[-\w]+)/$', 'object_detail', dict(info_dict, slug_field='slug', month_format='%m')), (r'^(?P<year>\d{4})/(?P<month>[0-9]{2})/(?P<day>\d{1,2})/$', 'archive_day', dict(info_dict, month_format='%m')), (r'^(?P<year>\d{4})/(?P<month>[0-9]{2})/$', 'archive_month', dict(info_dict, month_format='%m')), (r'^(?P<year>\d{4})/$', 'archive_year', info_dict), (r'^/?$', 'archive_index', dict(info_dict, num_latest=5)), ) Apesar da modificação nas URLs serem raras, a legibilidade da forma acima, queira ou não, prejudica numa eventual manutenção e a probabilidade de ocorrer um erro aumenta. Uma solução que ao meu ver facilita muito a leitura seria utilizando a função url(), como no código abaixo, retirado do django-fleshin: photo_detail = url( regex = '^(?P<album>[-\w]+)/(?P<slug>[-\w]+)/$', view = 'fleshin.views.photo_detail', kwargs = dict(photo_info_dict, slug_field='slug'), name = 'fleshin-photo' ) photo_list = url( # all photos + album list regex = '^$', view = 'django.views.generic.list_detail.object_list', kwargs = dict(photo_info_dict, paginate_by=FLESHIN_NUM_LATEST, extra_context={'album_list': Album.objects.all}), name = 'fleshin-photo-list' ) photo_album_list = url( # only photos in ``album`` regex = '^(?P<album>[-\w]+)/$', view = 'fleshin.views.photo_list', kwargs = dict(photo_info_dict, paginate_by=FLESHIN_NUM_LATEST), name = 'fleshin-photo-album-list' ) urlpatterns = patterns('', photo_detail, photo_list, photo_album_list) Perceba também que a forma acima facilita a reutilização dos patterns pelo seu projeto, não ficando preso ao que foi definido no django-fleshin, reaproveitando, por exemplo, o mesmo padrão de URL para o detalhamento de uma Photo (photo_detail) e alterando o padrão … -
EuroPython 2008, day 1
After a long year of exiting projects and neverending days at the office, I found myself again from EuroPython conference at Vilnius. The first conference day was full of interesting happenings, mainly reviving old and creating new connections. For all the sessions I attended during the day, I made some notes on few of them. Here are some basic notes about selected ones: ###Build an App in a Week by Marcin Kaszynski - [favpico.com](http://favpico.com/) etc - Suprisingly many of the attendees (about half) use Django - Use aDjango admin for users, too (not only for admins) - "Commit early, commit often" - Share code only via vcs - Use conventions - @with_template decorator - Note: you can use admin docs (template name) - Tests Do save time - self.login(), get, find - coverage.py - Instant Django This talk was interesting but didn't really give much new stuff (at least for me). There was a discussion about how it makes sense to use convention of naming templates like `app/viewname.html` but I pointed out that if you for some reason want to part from that convention (that I believe most Django developers use), you can just point Django admin site help section … -
Launching a High Performance Django Site
Are the brakes on your Django app? When building an application using an application framework like Django... the priority is often to get the application working first and optimize it later. The trade off is between getting it done and getting it done for 1 million users. Here's a check list of things you can do to make sure your application can be optimized quickly when you put on your optimization hat. Note, most applications don't need all of this since most applications do not get anywhere near enough traffic to justify even bothering. But if you're lucky enough to need to optimize your Django app, I hope this post can help you. Note, my background is in building very large high traffic sites for companies such as Fanball.com, AOL Fantasy Sports, eBay.ca, PGATour and NASCAR. All of those sites were built using ColdFusion/Microsoft SQLServer or MySQL or Oracle and I only recently jumped into Django. If you're familiar with fantasy sports, you know that you usually rush to a site to set your line up just before a sporting event starts and then you check your score when an event is live. This traffic is extremely high during those … -
Managing Database Changes in Django
Introduction Managing database changes in a team environment working on a django project can be complicated. I would imagine that there is no one size fits all solution and it would depend on team size and configuration, production database size, etc. What I will outline here is a solution I developed for a small team that I work with on a django based web application. So far it has worked really well for allowing us to streamline database changes so we can stay in sync, deploy easily, and add small tweaks to the database (indexing, data manipulation, etc.) that is semi-automated. The idea is based partly on Rails database migrations (though not has sleek and well put together) and a database versioning system that was used on a team that I have worked on previously using MS SQL in a corporate environment and a fairly decent team size. In one sense it is not nearly as well put together as either of these two solutions, but at the same time, it is pretty much hands off and has been working well for us for a number of months now. Why not just use syncdb? As nice as python manage.py syncdb … -
Managing Database Changes in Django
Introduction Managing database changes in a team environment working on a django project can be complicated. I would imagine that there is no one size fits all solution and it would depend on team size and configuration, production database size, etc. What I will outline here is a solution I developed for a small team that I work with on a django based web application. So far it has worked really well for allowing us to streamline database changes so we can stay in sync, deploy easily, and add small tweaks to the database (indexing, data manipulation, etc.) that is semi-automated. The idea is based partly on Rails database migrations (though not has sleek and well put together) and a database versioning system that was used on a team that I have worked on previously using MS SQL in a corporate environment and a fairly decent team size. In one sense it is not nearly as well put together as either of these two solutions, but at the same time, it is pretty much hands off and has been working well for us for a number of months now. Why not just use syncdb? As nice as <code>python manage.py syncdb</code> … -
Django Unit Tests and Transactions
While these are more properly integration tests than unit tests, it can be handy to have Django roll back the database transaction after each test method runs. -
Django Unit Tests and Transactions
Coming to automated testing in Django from the Zope and Plone world, I was pleased to find full support for all the testing machinery that I've become used to: regular Python unit tests, and doctests. Of course, these being unit tests, they don't do any 'framework' management out of the box. Unit tests are supposed to test your code, and just your code. However, once you're in a framework environment (be that Zope and Plone, Django, or anything else) then testing how your code integrates with that framework is vital. Zope and Plone provide unittest.TestCase subclasses (ZopeTestCase and PloneTestCase respectively) which provide a lot of scaffolding for you to be able to run integration tests. Part of that scaffolding is automatic transaction management. This hooks into Zope's transaction API to roll back the transaction after each test runs. I wanted to do something similar for my Django test cases; I was finding 'state pollution' between my unit test runs, since data created by one test method isn't automatically cleaned out. Django's transaction handling is much simpler than Zope's: it cares only about the one database transaction that the current request has, and only if the transaction support middleware is installed. … -
Django Unit Tests and Transactions
Coming to automated testing in Django from the Zope and Plone world, I was pleased to find full support for all the testing machinery that I've become used to: regular Python unit tests, and doctests. Of course, these being unit tests, they don't do any 'framework' management out of the box. Unit tests are supposed to test your code, and just your code. However, once you're in a framework environment (be that Zope and Plone, Django, or anything else) then testing how your code integrates with that framework is vital. Zope and Plone provide unittest.TestCase subclasses (ZopeTestCase and PloneTestCase respectively) which provide a lot of scaffolding for you to be able to run integration tests. Part of that scaffolding is automatic transaction management. This hooks into Zope's transaction API to roll back the transaction after each test runs. I wanted to do something similar for my Django test cases; I was finding 'state pollution' between my unit test runs, since data created by one test method isn't automatically cleaned out. Django's transaction handling is much simpler than Zope's: it cares only about the one database transaction that the current request has, and only if the transaction support middleware is installed. … -
Django Unit Tests and Transactions
Coming to automated testing in Django from the Zope and Plone world, I was pleased to find full support for all the testing machinery that I've become used to: regular Python unit tests, and doctests. Of course, these being unit tests, they don't do any 'framework' management out of the box. Unit tests are supposed to test your code, and just your code. However, once you're in a framework environment (be that Zope and Plone, Django, or anything else) then testing how your code integrates with that framework is vital. Zope and Plone provide unittest.TestCase subclasses (ZopeTestCase and PloneTestCase respectively) which provide a lot of scaffolding for you to be able to run integration tests. Part of that scaffolding is automatic transaction management. This hooks into Zope's transaction API to roll back the transaction after each test runs. I wanted to do something similar for my Django test cases; I was finding 'state pollution' between my unit test runs, since data created by one test method isn't automatically cleaned out. Django's transaction handling is much simpler than Zope's: it cares only about the one database transaction that the current request has, and only if the transaction support middleware is installed. … -
Plugging a RSS feed into a Django template
As some of you may have noticed, I've added my latest notes at byNotes in the sidebar. I wanted to do it in the template side, because I like to keep my views as clean as possible, so I wrote a template tag for fetching a RSS feed and displaying it. Here is the code: from datetime import datetime import time from django.core.cache import cache from django import template import feedparser register = template.Library() @register.filter def todatetime(value): return datetime(*time.localtime(time.mktime(value))[:6]) @register.tag def rssplug(parser, token): try: tag_name, address, template = token.split_contents() except ValueError: raise template.TemplateSyntaxError('%s tag requires 2 arguments' % token.split_contents()[0]) return RssPlugNode(address, template) def resolve(var_or_value, ctx): if var_or_value[0] == '"': return var_or_value[1:-1] return ctx.resolve_variable(var_or_value) class RssPlugNode(template.Node): def __init__(self, address, templ): self.address = address self.templ = templ def rss(self, addr): ckey = 'rssplug_%s' % addr data = cache.get(ckey) if data: return data data = feedparser.parse(addr) cache.set(ckey, data) return data def render(self, context): address = resolve(self.address, context) tmpl = resolve(self.templ, context) t = template.loader.get_template(tmpl) return ''.join([t.render(template.Context({ 'item': item })) for item in self.rss(address).entries]) As you can see, this tag uses a template for rendering every feed item, making it very flexible. You can output any information you want, as long as feedparser supports … -
Por: Juanjo
Creo que los dos enfoques tienen ventajas. -
Por: Gonzalo
¡Perdón! Confundí django-messages con django-notification, que no me gusta que la forma de usarlo sea inconsistente con la de una aplicación Django “normal” (qué se yo, pondría create_notice_type en un manager, y usaría get_or_create en vez del try/except que usa esa función), pero es solo gusto mío, nada para escandalizarse. Recién estuve viendo django-messages y ¡me parece genial!