I'm posting this here mostly because I need a more permanent home for this than my lappy's hard drive. I hope it's interesting to other people, though.
Anyway - this script is what I use to test Django against multiple versions of Python and multiple databases. To actually run this you'll of course need Python 2.3, 2.4, and 2.5 installed along with MySQL, PostgreSQL, and sqlite3 -- and the associated database wrappers for all 3 Pythons.
Yes, for the record, I've got all those things installed on my laptop.
If you can somehow make that work, though, running this script will print out a nice little summary of what's failing against which versions of Python and which database. Run with `-v` to see the actual failures.
Generic function to merge model instances. Useful when you need to merge duplicate models together, e.g. for users.
Based on http://djangosnippets.org/snippets/382/, with several enhancements:
* *Type checking*: only Model subclasses can be used and testing that all instances are of same model class
* *Handles symmetrical many-to-may*: original snippet failed in that case
* *Filling up blank attrs of original when duplicate has it filled*
* *Prepared to use outside of command-line*
ModelPagination
Designed and Coded by Cal Leeming
Many thanks to Harry Roberts for giving us a heads up on how to do this properly!
----------------------------------------------------------------------------
This is a super optimized way of paginating datasets over 1 million records.
It uses MAX() rather then COUNT(), because this is super faster.
EXAMPLE:
>>> _t = time.time(); x = Post.objects.aggregate(Max('id')); "Took %ss"%(time.time() - _t )
'Took 0.00103402137756s'
>>> _t = time.time(); x = Post.objects.aggregate(Count('id')); "Took %ss"%(time.time() - _t )
'Took 0.92404794693s'
>>>
This does mean that if you go deleting things, then the IDs won't be accurate,
so if you delete 50 rows, you're exact count() isn't going to match, but this is
okay for pagination, because for SEO, we want items to stay on the original page
they were scanned on. If you go deleting items, then the items shift backwards
through the pages, so you end up with inconsistent SEO on archive pages. If this
doesn't make sense, go figure it out for yourself, its 2am in the morning ffs ;p
Now, the next thing we do, is use id seeking, rather then OFFSET, because again,
this is a shitton faster:
EXAMPLE:
>>> _t = time.time(); x = map(lambda x: x, Post.objects.filter(id__gte=400000, id__lt=400500).all()); print "Took %ss"%(time.time() - _t)
Took 0.0467309951782s
>>> _t = time.time(); _res = map(lambda x: x, Post.objects.all()[400000:400500]); print "Took %ss"%(time.time() - _t)
Took 1.05785298347s
>>>
By using this seeking method (which btw, can be implemented on anything, not just pagination)
on a table with 5 million rows, we are saving 0.92s on row count, and 1.01s on item grabbing.
This may not seem like much, but if you have 1024 concurrent users, this will make a huge
difference.
If you have any questions or problems, feel free to contact me on
cal.leeming [at] simplicitymedialtd.co.uk
**I've since made a better snippet for this: [#2995](http://djangosnippets.org/snippets/2995/)**
based on [#1697](http://djangosnippets.org/snippets/1697/)
This one is even more generic since you can specify which fields to include or exclude, a custom description text for the drop-down menu and whether to output the header row.
there have been many posts on running django on tornado with static media served by nginx. But for dumb people like me, the whole thing needs to be spelt out. So here is how I succeeded in serving django from a virtual host using nginx and tornado. The key thing to note is that 'root' refers to the **parent** directory of the root and not the full path. Also remember to put in ':' as a line end. Procedure - start the tornado server with the python script on localhost:8888, start nginx. Relax and enjoy your django at the speed of light. Nginx can be got by apt-get or yum, but you need the latest git clone of Tornado - the default tarball does not support django. btw, this install is for FC11 on my laptop - I have done it in production on lenny.
An email address obfuscation template filter based on the ROT13 Encryption function in Textmate's HTML bundle.
The filter should be applied to a string representing an email address. You can optionally pass the filter an argument that will be used as the email link text (otherwise it will simply use the email address itself).
Example usage:
{{ email_address|obfuscate:"Contact me!" }}
or
{{ email_address|obfuscate }}
Of course, you can also use this on hardcoded email addresses, like this:
{{ "[email protected]"|obfuscate }}
This is an extended version of django wizard with the ability to go back
and execute any step directly.
To define next step to execute use the form field with the name
"wizard_next_step".
Don't forget to specify in your form the wizard_max_step field, so the
knows the step number with the highest number, where the user was.
An other improvement is the variable "wizard_data". It's a QueryDict with
data from all wizard forms. It can be used to retrieve values from the
field values of the forms from other steps. It could be helpfully for
the latest step, where the user should see an overview of his input.
Problem
=======
The FormPreview class provided by contrib.formtools helps automate a common workflow. You display a form, then force a preview, then finally allow a submit. If the form gets tampered with, the original form gets redisplayed.
Unfortunately, this class can only be used when you have an html form that is backed by exactly one Django form. No formsets, no html forms backed by more than one Django form.
Solution
========
I was asked to create exactly this sort of workflow for a highly complex form + formset. The ComplexFormPreview class provides a base class to help with this problem. As with FormPreview, you must override a few functions.
Code
====
The abstract ComplexFormPreview class can live anywhere on your python path. Import it and subclass is exactly like you would contrib.formtools FormPreview.
The self.state dictionary is passed to all response calls as the context for your templates. Add any objects you need in your template to this dictionary. This includes all forms, formsets, and any additional variables you want in your template context.
Override the parse_params if you need to get any args/kwargs from your url. Save these values in self.state if you want them in your template context.
Override the init_forms method to do setup for all of your forms and formsets. Save all your forms in self.state. You should provide a unique prefix for all forms and formsets on the page to avoid id collisions in html.
*VERY IMPORTANT NOTE*: init_forms is called with a kwargs dictionary. You need to pass **kwargs to all of your form definations in init_forms. This is how the POST data is going to be passed to your forms and formsets.
*VERY IMPORTANT NOTE No. 2*: all of the validation is handled inside the class - all forms will be found and validated, and we will only proceed when everything is found to be valid. This means that you can use the class as a view directly, or provide a thin wrapper function around it if you want.
Override the done method to handle what should be done once your user has successfully previewed and submitted the form. Usually, this will involve calling one or more save() calls to your various forms and formsets.
Because you now have multiple forms, the default contrib.formtools templates don't work. You must make custom templates that reference all of your various forms. The stage_field, hash_field, and hash_value fields are used exactly like the formtools examples. Follow the basic layout demonstrated in the example templates, and substitute your custom forms for the default form.
Example views.py
================
The views.py demonstrated here has many hooks into my project, including using some [complex formset classes](http://www.djangosnippets.org/snippets/1290/). It won't work for you without being customized, but it will demonstrate how to override the default ComplexFormPreview.
This middleware will look for the cookies set when a Facebook Connect user authenticates to your site, read those cookies, determine if the logged in user is your Facebook friend and then log that user into your Django-powered site.
If you don't need the bit about friend verification, it should be trivial to strip out.
There are a couple of other things that are needed to get FB Connect working with your site, and you can find a more detailed entry [here (http://nyquistrate.com/django/facebook-connect/)](http://nyquistrate.com/django/facebook-connect/).
As I was unable to find good examples to render an inlineformset together, I have posted this to Django snippets.
The example shows a person's data together with the phonenumbers for that person.
You can add, update and delete from this form.
This snippet defines a Widget that is very similar to the **SelectDateWidget** located in django.forms.extras.widgets. The main difference however is that it works with Times instead of Dates.
The SelectTimeWidget supports both 24-hr and 12-hr formats, and flexible time increments for hours, minutes and seconds. Sample usage is illustrated below:
# Specify a basic 24-hr time Widget (the default)
t = forms.TimeField(widget=SelectTimeWidget())
# Force minutes and seconds to be displayed in increments of 10
t = forms.TimeField(widget=SelectTimeWidget(minute_step=10, second_step=10))
# Use a 12-hr time format, which will display a 4th select
# element containing a.m. and p.m. options)
t = forms.TimeField(widget=SelectTimeWidget(twelve_hr=True))
A subclassed version of the standard Django Paginator (django.core.paginator.Paginator) that automatically caches pages as they are requested. Very useful if your object list is expensive to compute.
MIT licensed.
Django's serializer has some limitations which makes it a bit of a pain to use. Basically it will ignore any atributes that have been added to a model object.
The code below is for an alternative serializer. This version allows you select what attributes will be serialized on a per object basis. It also allows you to either serialize the data into json or xml.
The original json encoder was written by [Wolfram Kriesing](http://wolfram.kriesing.de/blog/)
Example Usage:
dumper = DataDumper()
dumper.selectObjectFields('class_name',[...fields...])
dumper.selectObjectFields('class_name',[...fields...])
dumper.dump(model_instance,'xml')
dumper.dump(model_instance,'json')
dumper.dump(queryset,'xml')
You're looking at the most-bookmarked snippets on the site; if you'd like to help useful snippets show up here, sign up for an account and you'll get your own bookmarks list.