Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
LFS News 2/2010
IRC Channel LFS has an IRC channel now: irc://irc.freenode.net/django-lfs Thanks to Simone aka simahawk. New Stuff Development: added pluggable payment methods Management: added static block also to the product class Management: added possibility to define a default variant Management: added deleting of existing file/image for categories Management: added pluggable distance criterion Checkout: added optional toc confirmation Search: added manufacturer and manufacturer id to searchable text Misc: all outgoing mails fail silently now Translations: Thanks to transifex we have a lot updates of translations Documentation: Added a lot of new documentation New Shop There is a new shop based on LFS: http://www.dilling-unterwaesche.de/ Work in Progress We are working on discounts and configurable products. There is also Michael's branch in the pipe, which will add country specific addresses. -
LFS News 3/2010
Today we released LFS 0.5.0 beta 1 - the first public beta release. What does this mean? No new features for the 0.5.0 branch - only bugfixes. The API is considered stable. Changes will go through a proper deprecation process. We will provide migration scripts for all future versions (if necessary). New Stuff Discounts Configurable products Product/Price/Property units Packaging units Improvements Send mail, when order state is changed to 'sent' Added exclude_from_navigation attribute to Page model Optimized top sellers Cleaned up contact form And a lot of bugfixes -
Djangocon and Django-BirdFlight
During my DjangoCon how-to talk I released Django-Birdflight, a project to help you name your Django project after a famous jazz musician, slang, etc. Very important stuff. Grab it. Slides coming soon. -
Released 0.5.0 beta 4
Today we released LFS 0.5.0 beta 4 What's new? Bugfix pages: caching page_view Bugfix cart: display correct stock amount within growl message Bugfix product_inline: display property title within error message Bugfix order_received_mail.html: display the correct selected values of a configurable product Bugfix cart: calculation of maximum delivery date Bugfix redirect: save redirect url for variants Bugfix lfs.page.views: added missing import of Http404 Bugfix: restrict adding to cart if the product is not deliverable. Issue #37 Added french translations (Jacques Seite) Added get_properties method to OrderItem Added optional cached parameter to cart/utils/get_cart_price and cart/utils/get_cart_costs Removed javascript which dynamically sets the height of the slots. Changed properties management: display name instead of title within left portlet Improved lfs.portlet: caching Further Information You can find more information and help on following places: Official page Documentation on PyPI Demo Releases on PyPI Source code on bitbucket.org Google Group lfsproject on Twitter IRC -
The apps that power Django-Mingus
Note: I migrating to a new URL scheme, so legacy comments are available here. After Mehmet S. Catalba launched a new Django-Mingus powered blog, yesterday, I thought it was time I sat down and wrote a brief description accompanied with brief annotations for each reusable app and how they fit into Mingus. The below discusses all 28 (34 actually but 6 are django.contrib apps I don't discuss here) reusable apps Mingus leverages. Django-Basic-Apps Source: Django-Basic-Apps Description: Simple prebuilt applications. Notes: I've launched a handful of blogs using the original, google code hosted, django-basic-apps. There's no bells and whistles but it simply gets the job done, and combine basic-blog with the included basic-media and basic-inlines you can get a long way. Nathan Borror provides a terrific collection of reusable apps in the greater basic-apps project and all are worthy of a visit from noobs and experienced developers. There's not only basic stuff in there so check it out. The basic-apps version that Mingus uses is a fork of Borror's original project by LincolnLoop to make it PIP compliant. I've added a Settings and BlogRoll models to the basic-blog. And I added a new app django-basic-elsewhere that replaces Mingus 0.1 dependency on … -
Released 0.5.0 beta 6
Today we released LFS 0.5.0 beta 6 What's new? Bugfix added_to_cart: Display correct taxes within added_to_cart view. Issue #65. Bugfix variants: display variant's properties on cart, added_to_cart, checkout, received_mail, sent_mail. Issue #40. Bugfix lfs.cart: fixed total of added_to_cart view. Issue: #38. Bugfix lfs.cart: subtract voucher price from cart price. Changed: provide own redirect middleware in order to redirect urls with query string. Further Information You can find more information and help on following places: Official page Documentation on PyPI Demo Releases on PyPI Source code on bitbucket.org Google Group lfsproject on Twitter IRC -
Screencast - Basic-Inlines and AdminImageWidget
Note: I migrating to a new URL scheme, so legacy comments are available here. Below is quick screencast, thanks to screenr, I published in response to some questions I received about how/why Mingus uses Nathan Borror's excellent basic-inlines application which integrates nicely with basic-blog. I also took the opportunity to show off AdminImageWidget which was contributed by Peter Baumgartner over on djangosnippets.org. -
South and Reusable Apps
Note: I migrating to a new URL scheme, so legacy comments are available here. I was honored to be invited to participate in a recent DjangoDose panel covering Reusable Apps in Django which featured Brian Rosner, Eric Florenzano, Alex Gaynor, James Bennett, James Tauber and Jannis Leidel. After listening to the episode I realized I offered up a "brain fart" when responding to @TheSeanOC's question "How should schema migrations be handled in reusable apps?". Let's review the brain fart I jumped in to answer the question quickly but my answer to this question was essentially "use South." Wow, great. Very enlightening. But I forgot to elaborate on the concept I've had in my head for a long time but have yet documented. As the callcast discussion related to this question continued the panel ended up agreeing that the best solution was making the use of South a convention. But in hindsight I wanted to offer something more. I had what I believe is an answer, or at least a suggestion for a solution. Remember in "A Christmas Story" when Ralphie went to the mall to ask Santa for his Christmas present wish? (No? it.). He froze up when he was … -
That apps that power Mingus 0.9
Extending my previous post The apps that power Django-Mingus, the best way to discuss what has changed in Mingus is to discuss the new apps. Well, wait just one second Ok, maybe the best way to begin is to quickly discuss a few higher level updates. The first, and one I'm very proud of, is that Mingus was recently added to Transifix and now has both Spanish and French translations included thus far. To be honest, Transifix wasn't the reason these two languages were added (two developers contributed them before Transifix came into the picture), but I can see it helping in getting the rest. Getting Mingus translated probably wouldn't have been possible if: I didn't focus on providing at least the basic pipeline for internationalization (templates, admin/models where possible) And if Pablo Marti and Florent Messa didn't come in and clean up where I left off. Thanks to those two Mingus now has Spanish and French translations. The fact is that so many apps (and I'm to blame here for some of my apps in the past as well) just don't do the basic i18n legwork that gets your app 80-90% of the way there. It's so easy, so … -
Eleven Django blog engines you should know
About two years ago Michael Trier blogged "Where's the Django Blog?". James Bennett later followed up with Where is the Django Blog Application in which he discusess why there is no "definitive" Django blog engine. More recently Daniel Greenfeld asked Show me your open source Django blog in which he defines various requirements needed for a project. Ever since reading that post I've been meaning to write this post. Below are a few blog engines I selected that I believe you should be aware of, sorted by most recently updated. If the author provided a description I used that. If not, I summarized what I know about the project. If you have your own blog engine we should be aware of, please post the name and url in the comments. Byteflow is not included because the project site is down at the time of this post. Biblion Tagline: The eldarion.com blog app intended to be suitable for site-level company and project blogs. Source: http://github.com/eldarion/biblion Last updated: Feb 9, 2010 Live example:http://eldarion.com/blog/ Description: Biblion was the eldarion.com blog which we've extracted and open sourced. It is currently positioned as being used for site/project blogs such as eldarion.com and pinaxproject.com. We intend … -
Integrating mongoDB and Django
After listening to Mike Dirolf talk about mongoDB at a recent Django-NYC meetup I was left wanting to learn more about mongoDB and how I could integrate it into my Django projects. Overview This screencast will quickly review places to learn more about mongoDB, and a few available Python APIs for working with mongoDB, particularly mongoengine. It also discuss a project that shows us how to leverage all the great things about Django and also integrate a NOSQL database into the mix. I stumbled onto the mongoEngine project about a month ago and have been meaning to post this screencast since then. What I like most about mongoEngine is that the classes structure looks and feels a lot like Django's models. I also really like its query API which also looks and feels a lot like Django's QuerySet API. Finally, I take a look at a Django powered tumblog project that uses mongoDB in the backend. This particular project leverages a custom authentication backend for handling application authentication, Django forms, Django views, templates, urls, etc. Essentially it uses everything but the ORM. This is not an extremely detailed tutorial -- my goal is to open up the discussion around a … -
2009 Django Dash Complete
The 2009 Django Dash is done. The site (http://alt.djangodash.com/) has the full commit logs and some interesting stats (overall, per team, per dasher). I'll do a better post-mortem tomorrow. Congratulations to all who participated and hope to see you next year! -
Postmortem: Django Dash 2009
Now that the Dash is over, I wanted to write up a little postmortem with some thoughts about how things went. To understate things, this year's Django Dash was amazing. In virtually every regard, the competition exceeded last year's contest. What Went Well First, a huge thanks to the sponsors. We went from 8 last year to 12 this year. Without them, there would be no prizes for the contest. We also doubled the number of teams that actively competed, which really impressed me. Many of the entries seem much more complete than last year as well. Using IRC & Twitter were also big wins. The IRC channel (#django-dash on Freenode) was where the party was most of the weekend (thanks to Eric for setting it up and admin'ing it). And being able to more easily/effectively distribute information via Twitter was nice (less infrastructure/headaches for me). Plus it was fun watching the #djangodash fly by. More stats and sparklines improved the website itself. I used the jquery.sparkline library and the new Aggregation support in Django trunk (soon 1.1), both of which proved easy to use and made it a little easier to spectate the contest. Bumping the team size from … -
Haystack 1.0.0-rc1
After almost a full year of development, Haystack has been marked as 1.0.0, release candidate 1. I'd recommend all users upgrade, as it is what Haystack 1.0.0-final will be unless any bugs are found. Should all go well, I'll be releasing 1.0.0-final next Sunday (Nov. 29, 2009). The release is available via git, via PyPi and as a tarball from GitHub. It's been a lot of work and lots of good contributions. I'm glad to finally be in the home stretch and will post something more substantial when 1.0.0-final drops. -
Haystack 1.0 Final Released
Haystack 1.0.0-final has been released (via the packages at PyPi or GitHub). You can also install it via ``sudo pip install django-haystack`` or via git from GitHub. The goal of Haystack is to provide modular search for Django. This means pluggable backends (Solr, Whoosh & Xapian currently), a reusable app architecture, the ability to add search to third-party modules without modifying their sources and a flexible codebase with many points of extension. The crown jewel is the ``SearchQuerySet``, which provides a ``QuerySet``-like interface to your search index. Included with the main install is everything needed to get basic search up and running in short order and yet powerful enough to provide search to some decent-sized sites. And there's a fair amount of documentation available. As with Django, Haystack will attempt to remain backward-compatible for the duration of the 1.X series, though there are no guarantees on this. Should a backward-incompatible change come up, I will post full disclosure on the changes on the mailing list as well as the commit itself. Some fun facts about Haystack's development: 315 days in development (from first commit to 1.0-final). 420 public commits with another 100 or so that were squashed. 27 people in … -
Better Local Settings
A common convention I've seen in the Django community is to place code like the following at the bottom of your settings file: # ``settings.py`` # Lots of typical settings here. # ... then ... try: from local_settings import * except ImportError: pass Then storing machine/user-specific settings within a local_settings.py> file. This file is set to be ignored by version control. I can't argue with needing overridden settings (do it all the time) but that import is backward in my opinion. My preferred technique is to still use the settings.py and local_settings.py but relocate the import. So local_settings.py starts out with: # ``local_settings.py`` from settings import * # Properly namespaced as needed. # Custom settings go here. DATABASE_HOST = 'localhost' The only other change is passing --settings=local_settings to any ./manage.py or django-admin.py calls. Trivial implementation, you still only need to override what you need, no changes needed to version control or development workflow. And since you've already imported all of the base settings, you can reuse that information to create new settings, like: # ``local_settings.py`` from settings import * DATABASE_NAME = "%s_dev" % DATABASE_NAME This is by no means a new technique, nor did I come up with it, but … -
Quickly Impersonate Another User In Your Django Project
I've created or worked on so many Django projects in the last 4 years that I find myself completely forgetting a project or client all together. It's sort of funny. Anyways... Too many times I've run into a situation where I, as an admin, need to impersonate another user on the system so I can verify a bug or issue that the user is experiencing. Over the years I've thrown together some internal methods to easily accomplish this. Well I finally got fed up with the process and decided to roll out a easily re-usable Django app to make it easy to do this for any Django project you may be working on. Drum roll please... Announcing Django-Impersonate OK, that wasn't as dramatic of an announcement as I'd hoped. In any case, you can clone django-impersonate on the BitBucket page for the app. It's also easily available via pip (pip install django-impersonate.) The app has a few helpful methods out the gate. A few views to actually start the impersonation, end it, list users, and search users. The search is just a basic query filtering on the username, first & last names, and email addresses of all the system users. … -
Exposing calendar events using iCalendar in Django
I recently wrote simple abstraction for exposing calendar events in Django as iCalendar feeds. It relies on vobject for managing the formatting of the calendar file, so you will need this if you want to try it out. It is available in Debian in the python-vobject package. Save this as a file somewhere in your project: import vobject from django.http import HttpResponse EVENT_ITEMS = ( ('uid', 'uid'), ('dtstart', 'start'), ('dtend', 'end'), ('summary', 'summary'), ('location', 'location'), ('last_modified', 'last_modified'), ('created', 'created'), ) class ICalendarFeed(object): def __call__(self, *args, **kwargs): cal = vobject.iCalendar() for item in self.items(): event = cal.add('vevent') for vkey, key in EVENT_ITEMS: value = getattr(self, 'item_' + key)(item) if value: event.add(vkey).value = value response = HttpResponse(cal.serialize()) response['Content-Type'] = 'text/calendar' return response def items(self): return [] def item_uid(self, item): pass def item_start(self, item): pass def item_end(self, item): pass def item_summary(self, item): return str(item) def item_location(self, item): pass def item_last_modified(self, item): pass def item_created(self, item): pass Now we need to couple this abstraction with a Django queryset. I placed this in a feeds.py in my application: from yourproject.path.icalendar import ICalendarFeed from yourproject.yourapp.models import SomeEvent class SomeEventCalendar(ICalendarFeed): def items(self): return SomeEvent.objects.all() def item_uid(self, item): return str(item.id) def item_start(self, item): return item.start def item_end(self, item): … -
Using Amazon S3 with Django
UPDATE: A commenter from this entry's submission on Reddit suggested setting up the CNAME to the S3 servers based on the bucket for your unique domain. By doing this, it will appear that the static files are hosted on your own servers instead of Amazon. A lot has been changing for this site lately. Not only did I switch hosting to the Python wonderland of WebFaction, but I also started serving static media -- CSS, JavaScript, images and other files -- through Amazon's Simple Storage Service (S3). Changing Web hosts from Dreamhost for this and my other Django apps was a must, but using Amazon's Web Service was more of an experiment really. Fortunately it's a cheap one: I owe Amazon eight cents for June. Follow the directions To get Amazon's S3 working for my site and Knox'd, I simply followed the directions published way back in 2006 by data wunderkind Adrian Holovaty. I'll paraphrase for readers of this blog: First, sign up for an Amazon S3 account. There is no charge until you actually use the service. Bonus: You can use your existing Amazon username and password like other purchases. Next you'll need to create a "bucket" for your … -
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 … -
About Django and the importance of releases
My favorite Python web framework, Django, has not been updated for a long time. The most current release, 0.96, was released in March 2007. This is a very long time, when you're in the market of web frameworks. This doesn't seem to bother a lot of people, as the common answer in the django community seems to be just to run the trunk version (development version). I for one doesn't like that solution. And here are some of the reasons why. Some of the problems with running a development version When a security release is made, I cannot just update, but need to merge the change in, in all of my installations. An update could maybe break my existing code with backward incompatible changes. It's easier to tell my co-workers that our projects will run 0.96, and not r6389 for one project and r7291 for another (+ a couple of security patches). That's okay if you are a single-person team working on a single project, but not when you have several people and projects. Developers are afraid to commit new things to trunk, because a lot of users will be disappointed when they eagerly update their repositories each morning just … -
Resources for Django on WebFaction
It feels like forever ago that patrickbeeson.com and a few of my other sites were hosted on Dreamhost. That is, of course, an increasingly distant memory now that I'm served by WebFaction's nearly fire-proof boxes. But making a Django environment stable wasn't as turn-key as their marketing might lead you to suspect (though it's easier than Dreamhost). In an effort to help future WebFaction Djangonauts, here are some most-read posts from WebFaction's excellent user-forum and knowledgebase. Domain transfer Note: WebFaction doesn't handle domain registration. You'll need to change your name servers to those used by WebFaction. Mine are still on Dreamhost. How can I add a new domain to my account? Apache configuration How do I stop/start/restart my Django Apache instance? How to fix errors like: ImportError: No module named django.core.management How do I serve static content? Running multiple Django sites from the same Apache/mod_python instance Django configuration Serving the Django admin media directly from the main Apache server How do I run the latest Django trunk? Cron + Django Script For Newbies - deploying your Django app Running "manage.py syncdb" Using Robots.txt file under Django in WebFaction Sending e-mails from Django Deploying A Django Application Memory usage Note: If … -
Django and mod_wsgi: A perfect match!
mod_wsgi is an Apache module for serving WSGI-based Python web applications from the Apache HTTP server. Django, along with almost every other Python web framework today, comes bundled with a backend for acting like a WSGI application. A couple of months ago I decided to try it out in spite of mod_python. Discovering and trying out mod_wsgi really suprised me. It can take a massive beating, and outperforms mod_python in every practical aspect. The setup You will need a short Python "bootstrap" script to create a WSGI-handler for your Django project. Here is an example (call it wsgi_handler.py and place it in the root directory of your Django project - the one with manage.py and settings.py): import sys import os sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..') os.environ['DJANGO_SETTINGS_MODULE'] = 'projectname.settings' import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler() Finally set up your Apache virtualhost to use mod_wsgi: <VirtualHost *> ServerName www.projectname.org ServerAlias *projectname.org Alias /admin_media /usr/lib/python2.4/site-packages/django/contrib/admin/media <Location /admin_media> Order allow,deny Allow from all </Location> Alias /media /home/user/projectname/media <Location /media> Order allow,deny Allow from all </Location> WSGIScriptAlias / /home/user/projectname/wsgi_handler.py WSGIDaemonProcess projectname user=user group=user processes=1 threads=10 WSGIProcessGroup projectname </VirtualHost> In the WSGIDaemonProcess line, you can easily manage the amount of system resources (measured in processes and threads) mod_wsgi should … -
'Practical' tips for working with Django
Everything I did building the content management system for this Web site was wrong. Actually, that might be an overstatement since this Web site works quite well (better than it did in Movable Type). But in the course of building a new Django content management system (CMS) that will drive the new, soon-to-be-launched Young Professionals of Knoxville Web site, I've learned a lot of useful techniques. Much of my new-found knowledge is due to Django Release Manager James Bennett's wonderful book "Practical Django Projects." Custom managers One of the critical needs for the new YPK site is the posting and display of events. At first, I figured this would require a standard model with the following fields: slug name location (ForeignKey to Location subclass) description event date start time finish time attire (With two options: formal and casual) category (ForeignKey to Category app) But then I realized that I would need a way to filter out events that are no longer current -- who wants to view old events? That's where custom mangers in models come into play: class CurrentManager(models.Manager): def get_query_set(self): return super(CurrentManager, self).get_query_set().filter(event_date__gte=datetime.date.today()) This allows me to filter all events whose date is greater than or equal to … -
Hacking Django forms for CSS flexibility
The default output of the Django forms (former newforms) module is not very CSS friendly. With a few simple adjustments, you can make your web designer colleague happy. This patch will add three classes on the parent HTML element of the rendering of each form field (the tr, li or p tag depending on your rendering mode): The type of the form field. (Examples: CharField, ModelChoiceField) The type of the widget. (Examples: TextInput, SelectInput) Is the form field optional or required: Optional or Required Now a required DateField will render, using the as_table rendering, as: <tr class="DateField TextInput Required"> <th> <label for="id_date">Date</label> </th> <td> <input type="text" name="date" id="id_date" /> </td> </tr> Example uses A couple of example use cases where my patch will help you out: Special styling of required fields possible. Easier to add a date picker by JavaScript. Special styling of checkboxes (styling input elements to width: 100% also affects those). Download the patch Patch against forms/forms.py in Django 1.0: Download - View How to patch your newly downloaded Django-1.0.tar.gz For those of you not quite familiar with working with patches: $ wget http://www.hacktheplanet.dk/export/HEAD/misc/forms.py.patch $ wget http://www.djangoproject.com/download/1.0/tarball/ $ tar xvfz Django-1.0.tar.gz $ patch -d Django-1.0/django/forms/ < forms.py.patch
