Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django-Mingus 0.2 Update
Note: I migrating to a new URL scheme, so legacy comments are available here. To keep those following up to date I wanted to post a list of features you can expect as we move towards the 1.0 version of Django-Mingus. For those using with the 0.1 version right now — you are completely fine. There is nothing "wrong" with the 0.1 version, and a few blogs are live with it right now, actually. But since the project gained some popularity I've decided it should be upgraded to a complete 1.0 version at some point in time. Just a reminder, Mingus is more about being an attempt at a learning tool first, and then a blog engine second. It's an attempt, I'm sure if you look you'll find areas to suggest better practices. And if you do, please post them for the community on the Django-Mingus issue list. The reason I mention this is because sometime you'll notice feature being introduced that simply exists to be a how-to, or a snippet being introduced that are popular utilities in your Django project that I normally use and I assume you may be interested in using yourself if you haven't heard of … -
LFS News 1/2010
After a long time, here are some updates about LFS: News: LFS moved to bitbucket: http://bitbucket.org/diefenbach/django-lfs/ Cleaned up documentation and added new stuff: http://packages.python.org/django-lfs/ New Code: Added vouchers Added redirects (based on Django's redirects app) Added pluggable templates (Jens Zeidler - iqplusplus) Added manufacturers (Michaela Hering - Demmelhuber) Added featured products (Michael Thornhill - Maithu IT Solutions) Added spain translations (sorry, I forgot who provided this :( Added more tests New live shops: http://shop.fischer-jugend.de/ http://ethnochicbazar.com/ http://www.molloyspharmacy.com/ http://www.gadgeteria.ru/ There are some more in the pipe (we'll give an update soon) What's coming next: Michael is working hard on integration of country specific addresses based on django-countries and django-postal (we hope we are getting it out of the door soon) I made some tests with a GXT-based management interface: Screencast. Will see whether this will go in LFS some time. Better documentation for users and developers Having more lfs-fun :) -
Favorite Django Tips
A few months ago I found a really useful Stack Overflow Question. Here are my favorites from the answers. Use render_to decorator instead of render_to_response This decorator is found in the app django annoying, and is a very nice shortcut for declaring what template a view should render. Instead of returning the response of render_to_response, you just return a python dict which will be used as the template context for the template specified as argument to the @render_to decorator. If anything else than a dict is returned, normal view processing will occur, so this won't break redirects or any other cases where you might return a HttpResponse (for example normal render_to_response code). Anyway, here is an example on how to use it: :::python @render_to("list.html") def list_posts(request): posts = BlogPost.objects.all() return {"blog_posts": posts} This equals to: :::python def list_posts(request): posts = BlogPost.objects.all() return render_to_response('list.html', {'blog_posts': posts}, context_instance=RequestContext(request)) Update (22/4): Marcin Nowak notified me that the render_to decorator breaks Django Reusable App converions, so I made a fork of django-annoying where I modified the render_to decorator to support template_name and extra_context keyword arguments. Load custom template tags in all templates Custom template tags that you use all over your templates can be … -
Introducing Django-Quoteme
I often posted quotes on my old blog at howiworkdaily, and I also maintain a collection of tesimonials over at my Monty Lounge Industries company website, so I figured it would be a good idea to release a reusable app combining the two. Because the two types are too similar to separate them into individual apps I placed them into one reusable app titled django-quoteme. -
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 …
