There is a lot of debate on whether there is a real future for the Django CBVs (class based views). Personally, I find them tedious, and just wanted a way to keep my views clean. So, here is a really minimalistic way of having class based views, without the fuss. This is a fork from: http://stackoverflow.com/questions/742/class-views-in-django http://djangosnippets.org/snippets/2041/
See code
See code
Tightens up response content by removed superflous line breaks and whitespace. By Doug Van Horn ---- CHANGES ---- v1.1 - 31st May 2011 Cal Leeming [Simplicity Media Ltd] Modified regex to strip leading/trailing white space from every line, not just those with blank \n. ---- TODO ---- * Ensure whitespace isn't stripped from within <pre> or <code> or <textarea> tags.
Some simple scripts which allow you to do nicer multi node / multi hostname hosting from within Django. Cal Leeming Simplicity Media Ltd
Read code for info
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
This basically takes the debug you get from setting debug=True, but instead, pipes it into an email and sends it over to you. I have extracted this out of our de framework, it should work, but some modifications may be necessary.
ReportBug() allows you to send exception details to you, via email, but with far more detail than the default. It uses the base function for the traceback used by the Debug mode on Django. This is a first revision, so the emails have no decent styling, but it works, and shows scope on each stack. It will automatically generate a random serial number per error, so you can track them in your favourite bug tracker. It also has support for you to pass it a request variable, so the mail would also contain request/response context. Again, i'm gonna look into doing this manually in the future. Hope this helps! Mwah. Cal Leeming. cal [at] simplicitymedialtd.co.uk. Simplicity Media Ltd.
*WARNING* This is *extremely* slow. This snippet allows you to easily prevent *most* race conditions (if used properly). Feel free to extend on top of this as you like, I'd appreciate any comments to [email protected]
This is useful when you need to convert a datetime.datetime.now() or datetime.date.today() into a unix epoch seconds, with microsecond precision (precision only applies to datetime.datetime, as datetime.date won't have any microseconds). I have found this is necessary for when storing the DateTime in the models as a FloatField, in order to keep the usec/microsecond precision. At some point, I will probably create a custom model field called DateTimeWithUSec or something like that, but for now, this will do :)
Because the db caching doesn't support atomic operations, it was unsafe to store a list of 'keys' in a single key. So, rather than store the list, I just append each key with a specific tag, and then filter for it later. This means I don't need to worry too much about atomic usage with lists (i.e. queued requests). However - I still can think of many instances where I would need atomic usage, so I will probably implement this later on down the line. Hopefully, the atomic modifications will be accepted by the core devs. This also contains threaded cache cleaning, which means you no longer need to rely on requests to clean the cache (which would have potentially slowed the user query down), and will remove any cache entries past their expiry date every 3 minutes. Enjoy! Cal
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages) I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order. This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
sleepycal has posted 13 snippets.