This decorator function wraps a normal view function
so that it can be read through a jsonp callback.
Usage:
@AllowJSONPCallback
def my_view_function(request):
return HttpResponse('this should be viewable through jsonp')
It looks for a GET parameter called "callback", and if one exists,
wraps the payload in a javascript function named per the value of callback.
Using AllowJSONPCallback implies that the user must be logged in
(and applies automatically the login_required decorator).
If callback is passed and the user is logged out, "notLoggedIn" is
returned instead of a normal redirect, which would be hard to interpret
through jsonp.
If the input does not appear to be json, wrap the input in quotes
so as not to throw a javascript error upon receipt of the response.
Usage described in this blog post: [Django: FileField with ContentType and File Size Validation](http://nemesisdesign.net/blog/coding/django-filefield-content-type-size-validation/)
Snippet inspired by: [Validate by file content type and size](http://djangosnippets.org/snippets/1303/)
When you neeed to do redirect and request object is not available, you can do it with exception.
Put exception handler somewhere request is available, for example to middleware or ModelAdmin.
Raise exception, where request is not available.
Just like it says -- set it up and run. Use it for server migrations, for project handoffs, in cron jobs, you name it.
I have never had problems exporting models to individual fixtures in this way, and only one bout of trouble re-importing them (and that was, like, an impossible-triangle of OneToOneField dependencies anyway, and they were going from a sqlite file to a postgres schema that totally had inappropriate nullable columns in it). I find that the json files named for what they contain is helpful when and if manage.py does freak out during an import, as the output from `loaddata` command is so opaque it's autistic, basically.
A trivial refactoring effort could make it into a management command -- it already makes use of the builtin `dumpdata` command class internally. However I did not feel like overthinking it enough to set it up in a repository (doubtlessly padded with unrelated 'utilities' and explanatory .rst files) and then writing a blog post to sell it to you. That is why you are reading this code here, instead of on GitHub.
Don't get me wrong, GitHub is awesome, and like a consummate host... but not the way I love me some quick and dirty snippet code, these days. Whatever, you say lazy, I say productively relaxed, potato/potahto.
Erm. In any case please do enjoy this model fixture-exporter. Yes.
This creates an RSS feed that has "content:encoded" elements for each item in the feed.
The "description" is best used for a brief summary of the entry, while the extra ["content:encoded"](http://purl.org/rss/1.0/modules/content#syntax2) element is designed for the entire contents of something.
This is the code I'm using for a weblog app. The main features you'd need to copy to add "content:encoded" elements to your own feed are:
* **ExtendedRSSFeed()** -- this is used to create a new kind of feed generator class that will know about these extra elements.
* **feed_type = ExtendedRSSFeed** -- we tell the feed class which feed generator class to use.
* **item_extra_kwargs()** -- we add the "content:encoded" element to each item. This populates the element by calling...
* **item_content_encoded()** -- this prepares the actual content. The name doesn't have to be in this format, but it seemed sensible to follow convention. The body of my weblog Entries are split into two parts and here it makes sure we add both parts, both of which contain HTML (which the syndication classes will encode appropriately.
I wanted a way to allow flexible phone number validation while making sure the saved data was uniform.
ex.
With:
RegexFormatField(r'^\(?(?P<area>\d{3})\)?[-\s.]?(?P<local>\d{3})[-\s.]?(?P<subscriber>\d{4})$',
format='%(area)s %(local)s-%(subscriber)s')
input:
(444) 444-4444
444 444-4444
444-444-4444
444.444.4444
4444444444
output:
444 444-4444
This code is taken from a [Stack Overflow answer by Will Hardy](http://stackoverflow.com/questions/3715550/creating-a-list-on-the-fly-in-a-django-template/3715794#3715794).
Usage: `{% collect var1 var2 'foo' 'bar' 5 as some_list %}`.
Sometimes one wishes to create a list on the fly within a template. Perhaps a collection needs to be passed to a template filter, but the collection cannot be created in the view since the values of one or more of its items are set in the template.
A contrived example:
{% with 5 as max %}{% with posts|length as len %}
{% for post in posts %}
{% if forloop.counter <= max %}
{% include 'excerpt.dhtml' %}
{% endif %}
{% endfor %}
{% collect len max as limits %}
<p>Displaying {{ limits|minimum }} of {{ len }} post{{ posts|pluralize }}.</p>
{% endwith %}{% endwith %}
The final line will state how many posts are displayed: something like "5 of 24" or "2 of 2".
This particular problem can be solved in a number of other ways, some of which are more appropriate. Having a template tag that can create lists on the fly is potentially useful in quite a few situations, though.
I don't know whether this need is common enough to warrant being in the core. If something like this is to be included one day, it'd be much nicer to overload the `with` tag than to introduce a new tag. `{% with var1 var2 var3 as some_list %}` reads well.
Unfortunately, it is not possible currently to use foreign keys in list filter of the admin website. list_filter=['city__country'] doesn't work.
This filter spec tries to workaround this problem.
It is also possible to have 2 filters for a foreign-key field but it requires to add a dummy field to the model. Set the fk_filterspec dictionnary on this dummy field and add 'fk':'real-field' to the dict.
Sometimes you might find useful to cache a value in different backends.
Just put this code in a file named "multicache.py" somewhere in your python path and set it in CACHE_BACKEND setting:
CACHE_BACKEND = 'multicache://?fallback=1&backends=file:///var/tmp/django_cache,locmem://'
Separate the backends settings with commas, the first one will be set as default.
Setting fallback to 1 provides fallback to default backend.
django-app-generator takes as an input your project (ORM) and generates repetitive code.
At this moment there is only one example a simple RESTservice, but goal is to build alternative
implementation of admin panel that will be fully customizable.
The project is in the beta stage, if you encounter any problems feel free to create an issue.