Phone Model
This is standart phone model.
- model
- phone
This is standart phone model.
This code provides a primary key field that is globally unique. It uses the pre_save method to auto-populate the field with a Universal Unique Id as the record is saved the first time.
This uses the Really Simple Color Picker in jQuery: http://www.web2media.net/laktek/2008/10/27/really-simple-color-picker-in-jquery/ Get source from there or GitHub: http://github.com/laktek/really-simple-color-picker/tree/master
Something I end up doing all the time, making a boolean variable show up as a nice image. With this code you can do the following: `{% boolean_img user.is_active %}` And get the following output: `<img src="/media/icons/accept.png" alt="True" />` All you need to do is use the custom templatetag code, load it in your template and use the `boolean_img` tag. **Adjust templates, html and images where needed**
This is exacly the same snippet as #197 http://www.djangosnippets.org/snippets/197/ but returning search enigne, search engine domain and search term in: request.search_referrer_engine request.search_referrer_domain request.search_referrer_term I wanted to show ads only to people comming from search engines so I took snippet #197 and modify it to put that info in the request object.
This was a wild experiment, which appears to work! One model holds all the data, from every object version ever to exist. The other model simply points to the latest object from its gigantic brother. All fields can be accessed transparently from the little model version, so the user need not know what is going on. Coincidently, Django model inheritance does exactly the same thing, so to keep things insanely simple, that's what we'll use: class EmployeeHistory(FullHistory): name = models.CharField(max_length=100) class Employee(EmployeeHistory): pass That's it! Django admin can be used to administer the `Employee` and every version will be kept as its own `EmployeeHistory` object, these can of course all be browsed using the admin :-) This is early days and just a proof of concept. I'd like to see how far I can go with this, handling `ForeignKey`s, `ManyToManyField`s, using custom managers and so on. It should all be straightforward, especially as the primary keys should be pretty static in the history objects... *updated 3 August 2009 for Django 1.1 and working date_updated fields*
Wraps specified URL patterns with login_required decorator. Allows you to quickly require login for an area of your site based only on a URL pattern. Similar to [zbyte64's snippet](http://www.djangosnippets.org/snippets/966/)
If any cache keys you generate include user (staff or public) supplied data, they may: be too long, contain invalid characters (at least by memcache's standards), or both. This helper will sub out any invalid characters and md5 the key if it's too long. Additionally, it'll insert the CACHE_MIDDLEWARE_KEY_PREFIX from django.conf.settings for you. In your memcache instances are used by multiple applications (Django or otherwise) this can help ensure your keys are unique to that a particular app on a particular site.
Base models aren't aware of its inherited models, here is a quick solution to access child models from the base model.
This form widget allows you to just display data in a rendered form, not giving the user the opportunity to change it. The initial data will just be carried through the form and showed to the user. In combination with snipped [1184](http://www.djangosnippets.org/snippets/1184/) you can make this even tamper safe. ;-)
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.
Works exactly like the standard "extends" tag but enables one to fallback on a default template. This tag is LIMITED, as it falls back to the next template with the same name that DOES NOT contain "extends_default" (does NOT simulate full inheritance, just a single level). A partial solution to problems like http://jeffcroft.com/blog/2008/aug/05/default-templates-django/. 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')
Format Number Based on Regular Expression **Examples** >*{{.1234|regex_comma_number:'%.4f'}} >*'0.1234' >*{{100|regex_comma_number:'%i'}} >*'100' >*{{ 234.5678|regex_comma_number:'%.4f'}} >*'234.5678' >*{{234.5678|regex_comma_number:'$%.4f'}} >*'$234.5678' >*{{1000|regex_comma_number:'%i'}} >*'1,000' >*{{1234.5678|regex_comma_number:'%.4f'}} >*'1,234.5678' >*{{1234.5678|regex_comma_number:'$%.4f'}} >*'$1,234.5678' >*{{1000000|regex_comma_number:'%i'}} >*'1,000,000' >*{{1234567.5678|regex_comma_number:'%.4f'}} >*'1,234,567.5678' >*{{1234567.5678|regex_comma_number:'$%.4f'}} >*'$1,234,567.5678' >*{{-100|regex_comma_number:'%i'}} >*'-100' >*{{-234.5678|regex_comma_number:'%.4f'}} >*-234.5678' >*{{-234.5678|regex_comma_number:'$%.4f'}} >*'$-234.5678' >*{{-1000|regex_comma_number:'%i'}} >*'-1,000' >*{{-1234.5678|regex_comma_number:'%.4f'}} >*'-1,234.5678' >*{{-1234.5678|regex_comma_number:'$%.4f'}} >*'$-1,234.5678' >*{{-1000000|regex_comma_number:'%i'}} >*'-1,000,000' >*{{-1234567.5678|regex_comma_number:'%.4f'}} >*'-1,234,567.5678' >*{{-1234567.5678|regex_comma_number:'$%.4f'}} >*'$-1,234,567.5678'`
After a point the sql server becomes the bottleneck in lots of web application, and to scale, master-slave replication with single master, multiple slave is recommended. This setup with nginx can be used to accomplish traffic distribution between master and slave based on request method.