This is an updated snippet based on http://djangosnippets.org/snippets/2260/
The updated snippet can limit the filtering options for a foreign key field to only those entries that are related to the current model. I.e. if you have an Author model with a FK to Institution model, you can configure Author's changelist to include a filter on Institution, but only allow you to select institutions that have authors. Institutions that do not have authors won't show up on the list.
To enable this, in your model's ModelAdmin class, set
<fieldname>_fk_filter_related_only=True
<fieldname>_fk_filter_name_field=<display this field of the related model in filter list>
For example, in your AuthorAdmin class, you can do
institution_fk_filter_related_only=True
institution_fk_filter_name_field='name'
Note that for the effect described above to work, you just need the last few lines of the big else clause in __init__, so if you don't care about filtering by FK property, you can just grab those few lines and create a simpler FilterSpec.
Testing low-level functionality sometimes requires a WSGIRequest object. An example of this is testing template tags.
This will monkey-patch the test Client object to return WSGIRequest objects
Normal Django behavior:
>>> client.get('/')
<HttpResponse >
With this code, get the request object:
>>> client.request_from.get('/')
<WSGIRequest >
Installation:
For this to work, you simply need to import the contents of this file.
If you name this file `clientrequestpatch.py`, do this inside your Django tests.
from django.test.testcases import TestCase
from myproject.test import clientrequestpatch
Just a quick solution to import product data from a excel spreadsheet to satchmo.
Supports
* hierarchical and multi categories
* product attributes
* product variations (configurable product, options)
* product price
* product image
Supposing you wanted to use a generic view, but you wanted to pass something over POST to show up in the resultant template. Perhaps you're creating a new object, and you want to pre-populate some hidden fields.
`urlpatterns = patterns('django.views.generic.create_update',
url(r'^obj/new$', view_post_vars_to_context(create_object), {'form_class': ThingForm, 'template_name': 'thing/new_thing.html', 'post_vars_to_context':{'obj_id':'objID'}, extra_context: {:this":"that"}}),
)`
Now objID will be a variable in your template, with the value passed via POST in the variable obj_id.
This is good for generic views, but there's no reason you couldn't use it for your own views if you really wanted, as long as you had an "extra_context" parameter.
For security, since POST variables aren't cleansed automatically, this only accepts values of "_" and "-". If you feel confident, you can alter this to your needs.
If your URL pattern looks like:
`urlpatterns = patterns('django.views.generic.create_update',
url(r'^obj/(?P<obj_id>\d+)/new_thing$', create_object, {'form_class': ThingForm, 'template_name': 'thing/new_thing.html', extra_context: {:this":"that"}),
)`
You will receive an error, because the create_update view doesn't have a parameter called "obj_id". Supposing you want that variable in the URL, and furthermore let's say you wanted to do something with it in the template. With this function, you can wrap the view, and add the parameter capture_to_context, which maps URL variables to template variables:
`urlpatterns = patterns('django.views.generic.create_update',
url(r'^obj/(?P<obj_id>\d+)/new_thing$', view_url_vars_to_context(create_object), {'form_class': ThingForm, 'template_name': 'thing/new_thing.html', 'url_vars_to_context':{'obj_id':'objID'}, extra_context: {:this":"that"}}),
)`
Now objID will be a variable in your template, with the value given to obj_id.
This is good for generic views, but there's no reason you couldn't use it for your own views if you really wanted, as long as you had an "extra_context" parameter.
This is a fairly straightforward view to generate iCalendar (.ics) files, with a unique UUID, a proper filename, and the basic fields needed to export an event from a public calendar (using the django-events-calendar app). While it can certainly be extended and adapted, it works very well as-is.
launch python manage.py yourcommand
and command output paste into http://www.yuml.me/diagram/scruffy/class/draw
todo:
1.implement other relation attributes
2.add class inheritance
3.download image automatically
4.generate diagram for specific app
This snippet implements an authentication backend for MoinMoin user accounts. If you have a MoinMoin running on the same server which has users, you can allow those users to sign into a Django site with the same username and password.
To use, define the following settings:
MOIN_DATA_DIR = "/path/to/moinmoin/data/dir"
AUTH_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',
'<this snippet module>.MoinMoinBackend',
)
# optional list of groups that authenticating users must be in
MOIN_AUTH_GROUPS = ["EditorGroup",]
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.
The popular [soaplib snippet](http://djangosnippets.org/snippets/979/) works only with older soaplib (0.8, for example). This snippet is modifed to work with newer soaplib: it was tested with 0.9.2-alpha3 and 1.0.0-beta4. I've tested suds python client and .NET client.
You're looking at the top-rated snippets currently on the site; if you'd like to contribute, sign up for an account and you'll be able to rate any snippet you see.