- Recent
- Popular
- Tags (0)
- Subscribers (6)
- Django Tip: A Never-Redisplay Form WidgetDecember 21 2008
- One situation when working Django's HTML form module has come up a couple of times recently: how to construct a form where redisplaying the form after validation errors have been found, will always blank out a particular field. This might come up if you always require a commenter to fill in a captcha field, even when they are just correcting errors. Just for fun, here are a couple of solutions. The Problem Typically, the people encountering this problem have deleted the value they don't want to re-render from the dictionary of data that they pass to the form. Something like this (let's suppose the field in question is called "captcha"): def form_handler(request, ...): if request.method == "POST": data = request.POST.copy() del data["captcha"] form = InputForm(data) ... The main problem I see with this sort of approach (and there are few variations, including removing the data in the form's rendering method) is that when all the other data is correct, this special field is never validated. It could almost have been left it out of the form in the first place, except that the form creator wanted it displayed on the HTML page. Another concern I have with this — and I suspect this is why a lot of people feel that there might be a "nicer" way — is that the data manipulation is separate from the rest of the form processing. Normally, you would pass all the submitted data to the form and that object nicely encapsulates the whole validati
- Goodbye, Pownce.December 15 2008
- Pownce.com closed its doors today. Companies do that from time to time. In this case, the two main engineers, Leah and Mike are working for Six Apart doing, I'm told, "interesting stuff." In my social connections piece, I mentioned that I didn't really get into Pownce as a user. But I did enjoy watching them grow and hearing little bits about the development behind the site as time went by. I've been thinking about them a bit the last few days, and here's a random collection of thoughts. A lot is going to sound obvious, which is kind of the point: Pownce was very normal and what happens in "normal" places is often not noted with the same kind of attention as paid to the more extreme case-studies. The technology behind Pownce, both hardware and software, wasn't anything particularly advanced or revolutionary. The concept was the interesting thing and is how they tried to differentiate themselves. But the difference between a business you see pop up and maybe later go away, and the business you only hear about at the bar when people are muttering about good ideas they have to do one day, is that the former group produces something. It exists and can be experienced. Leah, originally, and then in tandem with Mike, wrote code that got the job done. It wasn't necessarily world's greatest code at the start, but it worked. Nobody writes perfect code and nobody (if they're honest) can look at most things they wrote, even 12 months ago, and say "I would not do that differently no
- Content Types, HTTP And YouDecember 15 2008
- This is the third in a series on using Django to implement fine-grained HTTP control and RESTful services. A shorter piece today: inspecting request submissions' content types and setting the same for responses. For those arriving late, the previous posts in this series are here: Implementing HTTP Services With Django ETags And Modification Times In Django Processing Incoming Content Take Your Hands Off The Keyboard And Step Away From That Browser Assumption In the first piece in this series, I noted that Django has some built-in shortcuts for HTML form submissions. Not an unreasonable idea, since, if you're dealing with people viewing web pages in browsers, handling form submissions is a detail you'll have to handle with some frequency. The general case, working with arbitrary protocols that uses HTTP, requires more flexibility. There's no real limitation here, but be aware that there are also fewer shortcuts, since there can't be shortcuts. Django cannot read more mind and cannot handle every protocol known to mankind (including some not yet invented). Specifically, if you're used to using request.POST for processing form input, realise that it's only for processing form input. It's not useful (in fact, it's harmful) for processing non-form-encoded POSTs, along with other methods, such as PUT. When you access request.POST or request.FILES, Django does some decoding of the raw input data and treats it as a form submission, possibly including file up
- Know Your Django Red Letter DaysDecember 14 2008
- Partly because I was curious and so that I can find them again later, here's a list of major release and merge dates in the history of the Django source code (since it went public). 13 July 2005 Revision 1 of public Django subversion repository created. Created from revision 8825 of World Online's internal repository. 4 November 2005 i18n branch merged into trunk. 16 November 2005 Django 0.90 First public release. 25 November 2005 new-admin branch merged into trunk (revision 1434). 11 January 2006 Django 0.91 2 May 2006 magic-removal branch merged into trunk (revision 2809). 28 June 2006 multi-auth branch merged into trunk (revision 3226). 29 July 2006 Django 0.95 21 January 2007 Django 0.95.1 One minor security fix and a few bugfixes. 23 March 2007 Django 0.96 23 June 2007 boulder-oracle-sprinters merged into trunk (revision 5519). This added the Oracle backend to Django. 4 July 2007 unicode branch merged into trunk (revision 5609). 26 October 2007 Django 0.91.1, 0.95.2, 0.96.1 A security update, setting in place our policy of patching the latest release plus the two previous ones. 14 May 2008 Django 0.91.2, 0.95.3, 0.96.2 A security update. 27 April 2008 queryset-refactor branch merged intro trunk (revision 7477). 18 July 2008 newforms-admin branch merged into trunk (revis
- ETags And Modification Times In DjangoDecember 13 2008
- When I see somebody who wants to demo for me their latest "REST based" web service, the first thing I ask is; "do you support ETags?" — Sam Ruby, 2006 This is the second part in a series on implementing fine-grained HTTP controls and developing RESTful services with Django. The first instalment was last Tuesday. In today's piece, producing and consuming ETags, last modification times, and saving cycles whilst still ensuring everybody is happily using the latest data. This topic is really a lot easier than it looks from the length of this piece. I'm trying to be comprehensive and motivate the code, but if you only want the answers, skip ahead to anything that looks like Python code, by all means. ETags ETags or, more formally, Entity Tags, are a way to distinguish between versions of the same resource. There are two primary situations where ETags play a role: Conditional GET: Determining if a GET request really needs the response to contain all the data, or if we can tell it "nothing has changed since last time." Avoiding conflicting updates: If you PUT an update to a resource and I do the same thing, the server needs to ensure that we are both really updating what we think we are. If we start from the same document and your update lands first, my update shouldn't be accepted until I confirm I am updating the latest version. There are other cases, such as pre-emptively ensuring that a POST creates a record that doesn't already exist. Howe
