What Is Your Version Of Django
In my professional and personal projects I’ve run into alot of different versions of Django. Out of curiosity can you leave a comment indicating which version of Django you are using? Thanks!
More from Aware Labs
- Retiring Old Posts To Keep Django Fresh
- Constructive reasons to use Django instead of Rails (Proxied)
- Using Django Models In Batch Jobs
- Django Generic Relations Made Easier
- Django Deserializer Bug On Foreign Key When None
Aware Labs Recommends
- What Is Your Favorite CMS Platform (The Arkayne Blog)
- What Is A Blog Roll? (The Arkayne Blog)
- An Interview with Jacob Kaplan-Moss – Creator of Django (USwaretech)
Times change and so does Django, why would this blog be any different. I personally wish more people would do a little spring cleaning here and there. There are few things more frustrating than outdated posts derailing my searches.
So to keep it brief here are a few articles that are going away because frankly, they are no longer relevant:

- Auto Adjusting Pagination As A Template Tag Plus Include
- Why? Because Django now has this built in. - Digg Style Pagination In Django Revisited
- Why? Because Django now has this built in. - Adding Custom Actions To Django Admin Change Forms
- Why? Because Django now has this built in. - Shark Or Bear – Its A Killer Website
- Why? Because it’s no longer around. - New Django Site: Samz Market and Gourmet Foods
- Why? Because its no longer around. I miss you prosciutto sandwich.

- Digg For Django Is Here
- Why? Because I’ve moved on to other things. - Digg Re-Written In Django With A Twist
- Why? Because its no longer around. - Joost Meets Django
- Why? Because Joost has disappointed me. - Installing Django on Gentoo The Hard Way
- Why? Because Gentoo has disappointed me.
If you want copies of these, they are lost forever to the ether, my apologies. I’ve become less sentimental over the years.
More from Aware Labs
- Constructive reasons to use Django instead of Rails (Proxied)
- What Is Your Version Of Django
- Django Generic Relations Made Easier
- Using Django Models In Batch Jobs
- Django Deserializer Bug On Foreign Key When None
Aware Labs Recommends
- How To Write Better Blog Posts (The Arkayne Blog)
- Popularizing Django — Or Reusable apps considered harmful. (USwaretech)
- How Long Should Your Blog Posts Be? (The Arkayne Blog)
Google Gets Into VC Business
Recently all the major news papers have covered the same story. Google is getting into the VC space. Its nice to know the company that saved the web is now saving the VC market. Although I expected some new cool social investment platform instead of a simple. "We’ve got $100 Million to spend.". I guess its the Google version of a bailout.
Its getting attention:
![]() |
![]() |
![]() |

My biggest concern is their term sheets. Y-Combinator has your best interests in mind mainly because they don’t have the full expertise on hand to take over every project. With Google however, we are talking about a company that has built up a reputation for acquiring smaller ventures for no other reason than to corner the market. Take Grand Central for example, acquired shut down, and now cornered. So whats left to protect your ongoing involvement in any startup Google sponsors?
Typically there are a few things, talent, time to market, term sheets, IP, and sheer luck. Google has talent in spades. I guarantee they can get a product to market faster than anyone. Without looking at their term sheets I can’t be sure but I’m guessing their terms like all other Google agreements are stacked in their favor. You are definately out gunned in the IP department. As far as luck, Google makes its own. Any of the above are risks for any startup, the danger here is that they all come from one investor.
Would I let Google invest in my startups? I haven’t gotten an offer yet so I can’t tell you. Will I go out of my way to get an offer? No, for the reasons named above, but I will keep an eye on this one to see where it goes.
More from Aware Labs
- Everything A Django Developer Needs To Create Logins
- When Django Apps Grow Up
- Goodbye WebFaction Django Hosting – A Reflection
- Amazon EC2 Basics For The Curious
- Authenticating Using Email vs Username
Aware Labs Recommends
- The Hilarity of Working From Home (The Arkayne Blog)
- WordPress For Business (The Arkayne Blog)
- An Interview with Jacob Kaplan-Moss – Creator of Django (USwaretech)
Painless Amazon EC2 Backup
The past year on Amazon EC2 has taught me many things but first and foremost is back up consistently. I’ll say it again, back up consistently! Amazon even makes the backup almost painless, almost…
Amazon has EC2 (the compute cloud) and S3 (the data repository). Out of the box you can back up from EC2 to S3 using simple Amazon provided scripts like ec2-bundle-vol and ec2-upload-bundle. They both come already installed with the Linux images you start with.
I’ll inject some philosophy here. Some people believe that backing up the entire image is a waste of resources and you should instead back up only the data you need to S3. These people obviously have copious amounts of spare time on their hands. I’m not going to cry over the extra few MB, the benefit is being able to restore a backup in 30 automated seconds vs. twiddling with buckets and databases. Time is money.
The idea behind the code below is to backup entire images of a server on a rotating daily schedule. Rotation is set to create a unique manifest in your bucket per day of the week. If the system goes down or is compromised pick a backup day to restore, relaunch the instance from that image, and re-assign your Amazon IP address. The whole restore process should take no more than 30 seconds (Not counting instance boot).
To implement this backup strategy simply copy the following script into /root/backup.py and set up the following cron task (midnight backup):
crontab -e
0 0 * * * /root/backup.py
All codes above are fake but you should replace them with your own. Run the script manually or run it using the cron. Either way you get an automated painless Amazon EC2 backup.
More from Aware Labs
- Everything A Django Developer Needs To Create Logins
- Amazon EC2 Basics For The Curious
- When Django Apps Grow Up
- Goodbye WebFaction Django Hosting – A Reflection
- Porting Aware To Django
Aware Labs Recommends
- WordPress For Business (The Arkayne Blog)
- On Cloud 9 With Amazon EC2 (The Arkayne Blog)
- Popularizing Django — Or Reusable apps considered harmful. (USwaretech)
Outsourcing Revisited And No One Is Safe
The recent article Outsourcing Killed By Django And Ruby On Rails has caused as much proper debate as it has blind controversy. The feedback provided by readers here as well as other sites like Y Combinator and Reddit have brought up some good points. If I had to write the article again here is what I would change…

Drop the US as an example, define outsourcing relative to any geographic point. If you’re in Germany as US developer would be considered offshore. The same problems and the same numbers would apply.
Remove references to quality, focus on incurred cost of outsourcing. Quality is difficult to quantify and easy to debate. When frameworks like Django or Ruby On Rails effectively reduce core project development (coding) significantly enough, periphery project costs grow in proportion. Communication can become the bottle neck, for example. A time zone difference of a few hours (8 – 12 in the case of US to India) means project decisions have a significant lag. Over the phone or email communications are not as effective as face to face time, especially with cultural and language differences. Even with highly experienced staff the cost of doing business time zones apart is higher than face to face.
Avoid the term “low skill”, and focus instead on the risk of hiring talent you’ve never interviewed face to face. There is a reason Ebay, Google, Microsoft, YouTube, and so forth interview people in person before hiring. The risk of making a bad hiring decision that will cost significant dollars down the road drops after a good interview. How does one interview an individual several thousand miles away with the same level of confidence? You can’t, hence a risk of outsourcing that can be avoided by hiring local, which is made possible by frameworks like Django and Ruby On Rails.

Place emphasis on cheap labor as the target segment. Of course there are expensive developers everywhere, there are also cheap ones everywhere. Here in the US we have both, same as India, China, and Germany. Point is you get what you pay for and the mantra around outsourcing (at least here in the US) is cheap. Its a brand that was crafted by the outsourcing companies, now its back firing. Bean counters think dollars not skills and in US corporations bottom dollar wins out more often than not. So chances are if a US company outsources to India, it will outsource to the lower bidder regardless of skill.
Write a whole paragraph about how it doesn’t matter that developers in India or anywhere can pick up Django or Ruby On Rails. The frameworks have marginalized development to a point where its not the selling point. Communications, coordination, risk, and schedule are now selling points. The risks in those areas only get worse with off shoring or outsourcing across time zones.
Reference some of the frameworks in Java, PHP, and Perl that came before Django and Ruby On Rails. Yes, there were others but none as successful. Why? Ask the developers of Django and Ruby On Rails, they figured it out. For the rest of us, the important question is what does it signal for the future of web development. I’m guessing the end of off shoring, at least for a while.
Emphasize that Python is not Django and PHP is not Cake. Too many comments came back giving metrics for Java vs. Python or inferring PHP is the same as Cake. The discussion is around Django (not Python) and Ruby On Rails (not Ruby). Python itself reduces some development and coding because its an interpreted language with no type casts. Django on the other hand is a collection of functions crafted for the sole purpose of developing web applications. There is a huge gap between the two, thats why the focus is on the effects of Django on outsourcing.

The original message holds. No matter how you dress it up or how much mud gets flung at it, Django and Ruby On Rails are killing outsourcing. There will always be jobs, and like many readers pointed out, good developers will always have them. The difference will be that they will come from down the street instead of the other side of the world.
More from Aware Labs
- When Django Apps Grow Up
- Everything A Django Developer Needs To Create Logins
- Outsourcing Killed By Django And Ruby On Rails
- Goodbye WebFaction Django Hosting – A Reflection
- Authenticating Using Email vs Username
Aware Labs Recommends
- WordPress For Business (The Arkayne Blog)
- Django’s tipping point (Antonio Cangiano)
- An Interview with Jacob Kaplan-Moss – Creator of Django (USwaretech)
The absolute pinnacle of outsourcing madness peaked with the publication of “The 4 Hour Workweek” by Timothy Ferriss. The book was a Bible for starting your own sweat shop. Everyone from one man startups long forgotten to mega corporations like Ebay were looking to India, China, and eastern Europe to cut development costs. There is even a story, famous among cubicle dwellers, of an IBM engineer outsourcing his job to India, then using his free time to get and outsource another job at Motorola.
I guess if 80% of your job consists of writing many lines of code to achieve even the simplest task, like processing a login form, then 80% of it can be outsourced to lower skilled developers at a lower rate. A skilled and novice developer can churn out the 80% filler code almost at the same rate. Thats exactly why projects involving heavy C++, Java, Perl, and even PHP have been at the forefront of outsourcing. Those languages do not have a framework for rapid web development. When most of the work does not require creativity or great skill it will be outsourced. The math makes sense.
Take for example a project in Java requiring 100 hours at $80 an hour for a skilled US contractor. Thats an $8,000 price tag for 100 hours of Java code, not much considering the mundane complexity of getting anything accomplished in Java. Now take a developer from India, China, or Slovakia (formerly Czechoslovakia) for $20 an hour, you get 400 hours for the same price. Even the skill difference won’t be a risk. A low skill developer will be able to churn out 80% of the project in the same 100 hour time frame as a skilled one. Imagine all the basic for loops, form manipulation, and boring HTML boiler plate code written in any given project. That leaves another 300 hours to compensate for the skill gap. More than enough to mitigate risk in most cases. As a matter of fact you’ll probably be able to shave $4,000 off that price tag and still have a 100 hour buffer on a 100 hour project, 100% risk mitigation. Any bean counter will tell you, outsource, outsource, outsource…

Enter Django and Ruby On Rails….
I see it happening already, its subtle, both frameworks are a ripple on the non-corporate pond. In the coming months they will grow into tidal waves, forever changing the economics of outsourcing. The numbers are changing already. A local company, OpenRain using RoR, is able to complete monster projects for a few thousand dollars with a level of testing that would make aviation systems engineers salivate. Entrepreneurial developers at PayPal and Google are producing entire websites every other weekend. Its happening so it has to be possible, how you ask?
Frameworks like Django and Ruby On Rails have removed coding as a schedule bottle neck by removing mundane boiler plate code. That 80% is now gone, developers can focus on the 20% that delivers features for the project. No more assembling forms or creating database queries. The speed of development is now restricted purely by creativity. This works tremendously well for web applications because both frameworks were built with that space in mind. The 80% reduction in development costs shatters the economics of outsourcing!
The same 100 hour project with all the filler code obfuscated by Django or Ruby On Rails now takes 20 hours. A skilled developer at $80 will put the project costs at $1,600. Thats $2,400 cheaper than even the most optimistic $4,000 outsourcing estimates using Java plus outsourcing. That difference makes outsourcing a dinosaur compared to Dango and Ruby On Rails.
Some bean counters will be tempted to take it a step further. Why not outsource Django and Ruby On Rails work to low skilled low price developers?
Its not worth the risk. Outsourcing using Dajngo or Ruby On Rails using the sample 100 hour project, now reduced to 20 hours, will cost $400. Build in a buffer of 20 hours and the price tag is $800. Saving $800 over a higher skilled, more reliable, and more creative $80 an hour developer. That savings means you’ve effectively washed all creativity from your development team. Risk is through the roof, you have all the drawbacks of outsourcing concentrated in the most important 20% of your project development, the user facing features! Its not worth $800, be happy with the $6,400 saved.
This is already happening, its a fundamental shift in development. For corporations, once they catch on, it means huge savings even over outsourcing. For high skilled developers it means creativity and talent will be more important than ever. For low end outsourcing labor it means carving out a space in testing and data entry or being replaced. Oh yeah, Django and Ruby on Rails are exponentially speeding up all of the above!
More from Aware Labs
- Everything A Django Developer Needs To Create Logins
- When Django Apps Grow Up
- Goodbye WebFaction Django Hosting – A Reflection
- Outsourcing Revisited And No One Is Safe
- Installing Django And MySQL On MacBook Air Or OS X
Aware Labs Recommends
- Popularizing Django — Or Reusable apps considered harmful. (USwaretech)
- Django’s tipping point (Antonio Cangiano)
- An Interview with Jacob Kaplan-Moss – Creator of Django (USwaretech)
Clearing Django Form Fields One By One
I just spent an hour looking all over the web for something everyone assumes everyone else already knows. If you’re new to Django and you’re trying to clear a form field on validation then the solution is not intuitive.
Take a common scenario, you have a CAPTACHA image and the user enters it incorrectly, next time around you want to clear it and show an error, the rest of the form should be preserved. How do you clear a Django form field?
Wrong: Create a new form and copy the data across. This is not only overly complex, prone to error, and generally poorly readable code, its too much work. Don’t do it!
Correct: When populating the form from request.POST or request.GET make a copy of it and then clear the data attribute for that field. Here is an example:
The secret sauce is self.data['some_field'] = ”. The form itself does not contain any data, so trying to dig through the form attributes to clear a field is a dead end. If you do dig down deep enough, you will find that the form calls a widget method that goes to whatever data was associated with the form and fetches it. Hence clearing the data attribute works!
This makes sense to developers who’ve been around Django and its methodologies for some time. For novices the intuitive approach is to manipulate the form. Hope this gets picked up by enough searches to save others some time.
More from Aware Labs
- Everything A Django Developer Needs To Create Logins
- Goodbye WebFaction Django Hosting – A Reflection
- Django Generic Relations Made Easier
- Django Deserializer Bug On Foreign Key When None
- Modify Django To Support Binary Order By
Aware Labs Recommends
- Popularizing Django — Or Reusable apps considered harmful. (USwaretech)
- An Interview with Jacob Kaplan-Moss – Creator of Django (USwaretech)
- Django’s tipping point (Antonio Cangiano)
Link Exchange For Tough Times
Advertising on Google is getting expensive, very expensive. This year advertising costs for Adwords rose between 40% and 60% for some advertisers. Companies like eBags.com and Babyage.com have seen the cost of advertising online soar to 45% of the cost of the product they are trying to sell. Margins are diminishing and its only going to get tougher as consumers spend less.

Everyone dropping Adwords seems to be flocking to organic search. Caught in the middle are bloggers where Search Engine Optimization (SEO) competition has gotten brutal. SEO communities like Sphinn.com are soaring in popularity because bloggers are seeking any advantage over the competition. As authors spend more and more time promoting and optimizing, less time is spent on content and post quality. Its a vicious cycle thats going to lead to a blog bubble where the cost of blogging will outstrip most peoples resources.
Take or example a site by Nicholas Aretaki on relationships, Ditching Mr. Wrong. For Nicholas the costs of Google advertising became counter productive this year. He was simply forced out by multi dollar click through costs for the top Adwords positions. He’s shifted his efforts to SEO through an outsourced team with better results. Nicholas is fortunate, not everyone has the resources to hire an SEO team.
As the competition for traffic rises the game will have to change. I think all to often bloggers get caught up in the hype. Following every SEO trick of the day does not scale and cannot work. There are over 112 million blogs and growing on the web today. Webster’s Dictionary defines over 165,000 English words. Add an estimated 500,000 extra names, phrases, and slang words. Simple math yields 168 blog pages per Google keyword. Each blogger is competing for the top ten spots. Add all the other sites outside blogs and the numbers get even more daunting.
The point is that returns diminish quickly, the average blogger does not have the resources necessary to get to the top 10 spot and expect to stay there. As competition for the top spots on Google, Yahoo, and MSN heat up many blogs will simply not keep up in this economy.

The solution is as simple as it is frightening. Find alternatives. Before Google came around Yahoo and Lycos were thought to be the end all. Google changed the game and saved online advertising when it was about to burst by introducing page rank. All signs point to another bubble, crippling advertising costs, an SEO frenzy, and a hurting economy. Page rank is going bust, the saving grace this time will be relevance rank.
The new wave of relevance rank is already starting to swell. The first one out of the gate, Sphere just sold to AOL for $25 million. AOL stock jumped a tenth of a percent as a result of the acquisition. Following close behind is Zemanta which just received $2 million in seed funding from Union Square Ventures. Yet to be funded companies like Arkayne are starting to drive significant amounts of traffic based on relevance. Overall, alternatives to Adwords and Google SEO are starting to emerge for bloggers to take advantage.
The barrier to entry for these new relevance engines is nothing compared to popularity. Take Arkayne as an example. Any blogger embedding the widget creates ten instant links based on post similarity. Every outbound link has one or more inbound links in an Arkayne widget on another relevant post. If a more relevant post with higher relevance rank is added the list in every widget affected is updated. The result is a highly relevant set of links on every post driving traffic within a niche topic of interest.

The new technologies are not just shifting from popularity to relevance, some are looping in social and viral aspects of advertising. In the case of Arkayne, the widget provides an additional one click Get and Put link exchange between any two posts. The feature allows any reader to cross pollinate relevant links between blogs. Readers become a bloggers best tool for building reciprocal links.
Anyone interested in exploring relevance linking tools can request an Arkayne Invite.
More from Aware Labs
- Everything A Django Developer Needs To Create Logins
- When Django Apps Grow Up
- Amazon EC2 Basics For The Curious
- Goodbye WebFaction Django Hosting – A Reflection
- Outsourcing Killed By Django And Ruby On Rails
Aware Labs Recommends
- WordPress For Business (The Arkayne Blog)
- How to SEO your Blog Titles (The Arkayne Blog)
- The Top Tools For Promoting Your Blog (The Arkayne Blog)
New Django Site For Porsche Enthusiasts

Recently I’ve completed a revamp of Patrick Motorsports on the Django platform. The owner, James, has been working with Porsches for more than 15 years. He races Porsches, builds Porsches, and sells parts for Porsches. Overall its a cool shop, every time I’m over I see a dozen cars in various states of rebuilds and tune ups. We started working together over 5 years ago and the site has made some interesting evolutions since then.
2003 – We Met

It all started in November, when I called an ad for "Help needed building website for local Porsche business.", in the Arizona State University State Press. I called in, met James a few days later, I negotiated for beer money, he wanted to grow his business. We agreed and started things off fairly informally.
You should have seen his website, it still makes me chuckle. Imagine a middle aged man kneeling next to a transmission, with barely legible text poorly formatted on a single page as one giant image. That was it, no links, no other content, not even an email. Considering the web in 2003, many small brick and mortars were in the same predicament. The web was still owned by white collar silicon valley corporations and geeky college kids. James knew it was changing, PayPal was starting to catch on and Ebay was booming.
2004 – Starting Point

The first revisions were to create some real content. We took his entire PeachTree database of parts and exported it to a MySQL table. Over the span of a few weeks I layered on a C++ back end and a very simple non-CSS template. It worked for the 10 or so visitors he was getting each month.
He began promoting his website to other shops, at events, and on print material. I’m amazed by how different the small business auto industry web is from mainstream websites. Imagine a world where customers think state of the art is five years ago and whats on some of the most successful websites is not what they want. It was tough going but James and I managed to get some key elements on Patrick Motorsports.
The biggest seller to this day has been the Project Gallery. Its a section of the site where James can document the various stages of a build in photos. From looking at Goolge Ananlytics, over 70% of our traffic came in from the gallery. To improve sales, we added a parts list for every build. It worked sales started to climb.
2005 – Getting Bigger

Initially James and I had planned on linking in with PayPal but decided against it until his internal processes were fine tuned. When sales picked up to a point where customers were asking for online checkout, we settled on a order by email system as a stop gap. Any order you place on the Patrick Motorsports page is reviewed and processed by email.
It actually worked in his favor considering the nature of his business. We’re talking about a shop that builds cars worth many tens of thousands of dollars for specific customers. James had a reputation and a standard of quality to preserve. Rushing into impersonal online sales too soon would have been risky. Email and phone based orders allowed him to fine tune each order with the customer, ensure the parts fit the customers vehicle model, and make each customer understand how absolutely knowledgeable and dedicated he is to his trade.
Late in the year Brian came on board to help with the growing number of parts. The site was beginning to outgrow itself, the old C++ code was getting tough to manage. We needed someone to come in and update all parts, prices, projects, links, and descriptions. Customers would call in and mention how it was difficult to find a specific part. Brian was the young kid who knew about cars, was an excellent graphics artist, and picked up the website super fast. Over months he built up the photo and parts library from a few dozen to thousands. You can now spend days browsing through all the content.
2006 – Taking A Break

Not much happened to the site that year. I was in Tucson working for Tucson Embedded Systems. James was busy growing business and expanding his shop. We made minor changes to the site but nothing huge.
2007 – Going Django

In October, James decided to make the site more user friendly and take ore of an Amazon style approach to product recommendation. The gallery and exclusives sections were becoming hard to manage. Cross linking all the parts was taking more and more time. We decided to redesign the administrative interface.
We quickly realized C++ wasn’t going to cut it. It would take less time to develop the site from scratch in Django and provide us more flexibility down the road. By mid September we had a the new site up and running. Instantly we saw bounce rates in Google Ananlytics cut in half while page views sky rocketed. The revision was a success!
The trick was the extensive product recommendation. We wanted every single page on the site to flow into more options. The Patrick Motorsports site is so heavily cross linked you can browse through all the parts maybe 12 different ways and never get lost. Cars link to parts, parts link to projects, projects link to specials, specials link to catalogs, catalogs link to parts, etc… Basically everything links to everything and the back end alows one person to administer it all sanely.
2008

The past year has seen a shift in focus, all the numbers are good but they could be better. James is focusing his efforts on external marketing. We are taking SEO seriously and going after more traffic aggressively. I see it as another phase in an incredible project that has come a long way since the strange one page website.
Last week we kicked off a whole new design for the menu as well as the home page. With cool cascading menus and improved home page navigation the site really pops. As far as car part sites go, this one has the best mix of navigation, information, and eye candy. The next few months will be exciting as Patrick Motorsports expands projects and part selection even more.
If you’re an interested Porsche enthusiast, James gives tours. You haven’t fully appreciated speed until you’ve driven his 1973 Porsche 911 RSR – 3.8L at full throttle.
More from Aware Labs
- Everything A Django Developer Needs To Create Logins
- When Django Apps Grow Up
- Goodbye WebFaction Django Hosting – A Reflection
- Amazon EC2 Basics For The Curious
- Authenticating Using Email vs Username
Aware Labs Recommends
- WordPress For Business (The Arkayne Blog)
- Popularizing Django — Or Reusable apps considered harmful. (USwaretech)
- Django’s tipping point (Antonio Cangiano)
I’ve seen many posts asking for the simplest feature in Django admin… the ability to add custom actions next to History and View On Site in the Django admin form. The page where the actual object is edited, not the list pages. Imagine adding actions like:
- Edit Next Item
- Edit Previous Item
- Send Thank You Email
- Export Record As CSV
Thats just the tip of the iceberg. Basically any action can be performed. The concept is simple, create an buton for an action, redirect to a handler with model and id of object, execute any code, then redirect back to the admin page. This would turn Django admin into any application the developer chooses.
I first wrote on this topic in Adding Custom Actions To Django Admin Change Forms, back when Django was in version 0.95. I’m writing this post again to document the code port from 0.96 to 0.96 and above.
Changes To Django
First add code to Django to facilitate custom actions. Working backwards from the template is the simplest way to visualize the changes.
Step One: Add a list of custom actions to the Django admin change form template. I added the for loop…
contrib/admin/templates/admin/change_form.html
You may have noticed that the custom action will call a URL of the format /admin/handler/model/id/. I think its simple and provides enough information to identify the object being edited in all circumstances. There may be some overlap with admin URLs so please be careful or change the URL here.
Step Two: Add a member to the Django admin change form handler to be passed into the template. This is just a one liner, add form_action to the context dictionary.
contrib/admin/views/main.py
Step Three: Add the new custom form_actions field to the Admin class. You’re really adding it to the AdminOptions class, but you get the picture. I added the form_actions to the function signature and the list of member variables.
db/models/options.py
Those three files is all you have to edit. Now you have support for custom actions. I assume you’re OK with the custom action protocol I implemented above. If you want to change it then I leave the edits up to you. If you take me at my word, then all you have to do is add the proper code to your models file and your URL handlers.
Your Custom Handler
All the pieces are in place on the Django admin side. Now to create a custom handler.
Step One: Add a list of actions to your model definition under the Admin class.
models.py
If you refresh your Admin page here you will see the new custom action.
Step Two: Create a handler for your new action in the URL handler. Remember if you use admin as your prefix then place the handler regexp before the one for Django admin.
urls.py
You’re done. Add as many custom actions as please you. I recommend redirecting back to the Django admin page after executing each action. You have the model id and the object id, you can even create generic handlers for any object. In my case I typically only use the object id, each handler is model specific in my case.
Request To Readers
I would really like it if this feature was included in the official Django release. Please leave a comment in support of this code. I would like to approach the Django maintenance group and petition a feature request based on your comments. The more comments in support, the more likely we will see this in the official Django version.
More from Aware Labs
- Everything A Django Developer Needs To Create Logins
- Goodbye WebFaction Django Hosting – A Reflection
- When Django Apps Grow Up
- Implementing CNN style votes in Django, Episode I
- Implementing CNN Style Votes In Django, Episode II
Aware Labs Recommends
- Popularizing Django — Or Reusable apps considered harmful. (USwaretech)
- Django’s tipping point (Antonio Cangiano)
- An Interview with Jacob Kaplan-Moss – Creator of Django (USwaretech)




![Recommend [AwareLabs]](http://s3.amazonaws.com/arkayne-media/img/badge/logo-recommend-badge-medium.png)