This is a custom widget for displaying a view only date field in the django admin. I used it to get around this ticket: [http://code.djangoproject.com/ticket/342](http://code.djangoproject.com/ticket/342)
I wanted to be able to limit which types of requests a view will accept. For instance, if a view only wants to deal with GET requests. @methods(GET) def index(request): # do stuff Now, calling this view with a non-GET request will cause a 403. You can easily change this to a 404, by using a different return function: which you may wish to do with openly available sites, as a 403 indicates there is a resource present.
The above code contains the file name fetches random images from the database. Using the JQuery this image is displayer in the page
With this, you can group form fields very easily. Since it does not create any html, you can use it not only to create fieldsets (with tables, lists, etc).
Requires the M2Crypto module. See [http://sandbox.rulemaker.net/ngps/m2/howto.smime.html](http://sandbox.rulemaker.net/ngps/m2/howto.smime.html) for more information on using M2Crypto to create S/MIME email. This could also be adapted to allow signing, or sign+encrypt, but currently only encrypts. Use just like `EmailMessage`, except takes an extra parameter `cert`, which is the path to the recipient's public X.509 certificate.
If you have a relatively small finite number of categories (e.g. < 64), don't want to add a separate column for each one, and don't want to add an entire separate table and deal with joins, this field offers a simple solution. You initialize the field with a list of categories. The categories can be any Python object. When saving a set of categories, the field converts the set to a binary number based on the indices of the categories list you passed in. So if you pass in as your categories list [A,B,C,D] and set model.categories = [C,D], the integer stored in the database is 0b1100 (note that although the categories list has a left-to-right index, the binary number grows right-to-left). This means that if you change the order of your category list once you have data in the DB, you'll need to migrate the data over to the new format. Adding items to the list should be fine however. If you need to do filtering based on this field, you can use bitwise operators. Django currently (to my knowledge) doesn't support this natively, but most DBs have some bitwise operator support and you can use the extra function for now. For example, this query will select CheeseShop models that have the 'Gouda' in its cheeses field. `CheeseShop.objects.all().extra(where=['cheeses | %s = cheeses'], params=[CHEESES.index('Gouda')])`
Simple middleware+decorator to handle age verification. Modeled after `django.contrib.sessions.middleware` to add an attribute to `request.user` called `is_age_verified` with consideration to [snippet 1002](http://www.djangosnippets.org/snippets/1002/). Decorator modeled after `django.contrib.auth.decorators.login_required` Installation: Create `verify_age` URLconf in `urls.py` Create age verification page that URLconf points to Define `settings.VERIFY_AGE_URL` based on URLconf Add `age_verification.AgeVerificationMiddleware` to `MIDDLEWARE_CLASSES` Import both `age_verification_required` and `REDIRECT_FIELD_NAME` in `views.py` Implement `age_verification.AgeVerification.verify` somewhere to set session attribute on successful verification. Use `@age_verification_required` decorator for views requiring age verification Example urls.py: urlpatterns += patterns('mahalo.answers.views', ... url(r'^verify_age/?$', 'verify_age', name="verify_age"), ... Example settings.py: ... VERIFY_URL = '/verify_age/' ... MIDDLEWARE_CLASSES += ( ... 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'myproject.contrib.middleware.age_verification.AgeVerificationMiddleware', ... Example views.py: from myproject.contrib.decorators import age_verification_required, REDIRECT_FIELD_NAME from myproject.contrib.middleware.age_verification import AgeVerification ... @age_verification_required def some_view(request): return render_to_response("index.html", {}) def verify_age(request): # project specific template_vars = default_template(request) # form was posted if request.POST.has_key("month") and request.POST.has_key("day") and \ request.POST.has_key("year"): # "verify" user av = AgeVerification(request.session) av.verify() if request.POST.has_key(REDIRECT_FIELD_NAME): return HttpResponseRedirect(request.POST[REDIRECT_FIELD_NAME]) else: return HttpResponseRedirect(reverse("root")) # no form posted, show it else: if request.GET.has_key(REDIRECT_FIELD_NAME): template_vars["next"] = request.GET[REDIRECT_FIELD_NAME] return render_to_response("verify_age.html", template_vars) These examples assume `age_verification.py` lives in `myproject/contrib/middleware/` and `decorators.py` lives in `myproject/contrib/`
A quick and dirty helper for model field `choices`. It's not perfect, but this is what I use.
The proper looking email links rendered to the browser are not in the source code that way, and are rendered by javascript, so robots can't extract it. Its a trick way to have the email displayed properly without getting spamed as a result. Unless the robots are getting smarter, this has worked for me thus far.
Although many people have already posted cookieless session middlewares and related stuffs, but this one is just for only required views. You can use this as a view decorator like: @session_from_http_params @login_required def your_view(request): ... This is very useful for those who use SWFUpload. Flash has a bug with sending cookies properly, so SWFUpload offers an workaround -- session key as a POST parameter.
This snippet helps preserving query parameters such as page number when the view perform redirects. It does not support hooking templates and contexts currently.
When running the Django development server, this middleware causes all executed SQL queries to get printed out to the console. This is based on [Snippet 161](http://www.djangosnippets.org/snippets/161/). The big difference is that 161 logs by adding stuff to your response text, which isn't very convenient IMO.
This code uses oracle as an authentication back end. It creates a new connection to the db and attempts to login. If successful it will then create an upper case User account with _ORACLE appended to the username. My urls.py call: from django.conf.urls.defaults import * urlpatterns = patterns('', (r'^accounts/login/$', 'django.contrib.auth.views.login', {'template_name': 'login.html'}), ) My setting.py specific settings: AUTHENTICATION_BACKENDS = ( 'oracleauth.views.OracleAuthBackend', ) LOGIN_URL = '/accounts/login/' ORACLE_CONNECT = 'database-host:1521/database' DEBUG=True
See docstring
When you call model.changed_columns() you get a dict of all changed values. When you call model.is_dirty() you get boolean whether or not the object has been changed since last save Based on an answer here:http://stackoverflow.com/questions/110803/dirty-fields-in-django but fixed and added is_dirty