shortcut for saving newforms to model
I come up with this short cut of saving data from newforms to a model, for newforms that contains attributes from several models or some attributes that doesn't found in a model attributes
- newforms
- model
Snippet List
Incrementally Return CSV
The first function (ftype_batch) is a view that passes the first part of the CSV filename and a queryset intended to write out to the file. run_batch prepares the HttpResponse for incrementally writing, and write_batch actually writes out the data. The logic in write_batch is custom to what I need done, but as long as the csv writer receives a sequence to write, it should work.
- csv
- incremental
Using reverse() to do redirects
When I initially set up my blog, I put together the archives with URL patterns like so: * `/weblog/2007/` goes to `archive_year` * `/weblog/2007/08/` goes to `archive_month` * `/weblog/2007/08/24/` goes to `archive_day` * `/weblog/2007/08/24/some-slug` goes to `object_detail` The same patterns held for links, only the prefix was `/links/` instead of `/weblog/`. For a forthcoming redesign/rewrite, I'm switching to using abbreviated month names (e.g., "aug", "sep", "oct", etc.) in the URLs, which means I need to redirect from the old-style URLs to the new. This snippet is the solution I hit upon. Two things are notable here: 1. Each one of these views uses [reverse()](http://www.djangoproject.com/documentation/url_dispatch/#reverse), called with the appropriate arguments, to generate the URL to redirect to. This means URLs don't have to be hard-coded in. 2. Each view takes an argument -- `object_type` -- which is used to generate the view name to pass to `reverse`, meaning that only one set of redirect views had to be written to handle both entries and links. This is just one of many handy tricks `reverse` can do :)
- urls
- reverse
- redirects
Judge login require by url
Simple code , judge login require by url
- url
- login
- require
pygments stylize
Simple tag to enable easy parsing of inline code within a template. Usage: {% stylize "language" %}...language text...{% endstylize %}. Make sure to set the language for Pygments to parse as the first argument to the tag. You will also need to include a copy of the CSS that Pygments uses. The [Pygments](http://pygments.org/) library is required for this tag.
- pygments
- templatetags
Extended rails flash implementation
This is an extendend version of the Rails Flash implementation by Sean Patrick Hogan that supports different message types. **Setting a flash message:** request.flash.error = 'Item could not be saved' request.flash['error'] = 'Item could not be saved' request.flash['foo'] = 'bar' **Displaying a flash in the view:** <!-- show the error message --> {% if flash.error %}An error occured:{{ flash.error }}{% endif %} <!-- just show the first message found --> {% if flash %}An error occured:{{ flash }}{% endif %} <!-- show all messages --> {% for msg in flash %}{{ msg.type }}: {{ msg.msg }}{% endfor %} Note that it still works with simple strings as well. Feel free to just use it like this: request.flash = "Message" And: {% if flash %}{{ flash }}{% endif %} However, be aware that once you did this, you destroyed the Flash() dict and thus lost the extended functionality. You can use request.flash.clear() to remove all messages.
- flash
- messages
- rails
DefaultValueWidget
Can be used if a form field should not be editable, but the current value or the value that will be automatically used should still be visible to the user. __init__ takes two additional parameters: **value** is the actual value to be used when saving the form, while **display** determines what is shown to the user when rendering. If *display* is not specified, *value* itself will be used instead. If *display* is a *ModelChoiceField*, *value* is assumed to be a primary key of the model, and the widget will automatically try to retrieve and use the string representation of the corresponding item.
- newforms
- forms
- widgets
- widget
instant 'master' admin site
The newforms-admin branch (to be merged by 0.97, I think) is very nice to work with, separating models from the admin. It is trivial to create an admin site that includes every app that is installed. Note that you also get all your docs for things like template tags, etc.
- admin
- newforms-admin
DRY with common model fields
If you have many models that all share the same fields, this might be an option. Please note that order matters: Your model need to inherit from TimestampedModelBase first, and models.Model second. The fields are added directly to each model, e.g. while they will be duplicated on the database level, you only have to define them once in your python code. Not sure if there is a way to automate the call to TimestampedModelInit(). Tested with trunk rev. 5699. There is probably a slight chance that future revisions might break this.
- models
- model
- inheritance
Feed Reader Inclusion Tag
This is an inclusion tag that can be used to pull in posts from any feed to a template. It doesn't do any caching, so it may slow down page load times. Depends on [Feedparser](http://www.feedparser.org). Template usage: {% pull_feed 'http://www.djangosnippets.org/feeds/latest/' 3 %}
- feed
- rss
- inclusion-tag
keeptags: strip all HTML tags from output except a specified list of elements
Django has several filters designed to sanitize HTML output, but they're either too broad (striptags, escape) or too narrow (removetags) to use when you want to allow a specified set of HTML tags in your output. Thus keeptags was born. Some of the code is essentially ripped from the Django removetags function. It's not perfect--for example, it doesn't touch attributes inside elements at all--but otherwise it works well.
- filter
- html
- escape
Using dojo/json to check for username availability
An example of using Dojo to retrieve some information from a view (linked by the URL '/account/isavailable/') to show whether or not an account is available.
- json
- dojo
- username
- register
Simple solution for model schema evolution / database changelog
This is a very simple approach to "schema evolution" (Not sure if you can even call it so) - I use it for my project: [SCT](http://sct.sphene.net) and it seems to work quite nicely. The idea is, that if you add or change your models, you add a 'changelog' attribute to your class which defines the SQL queries required to update your models. Of course this only works for one database type... An example 'syncdb' call if a new changelog entry was detected: kahless@localhost ~/dev/python-new/sphenecommunity/sphenecommunity $ ./manage.py syncdb Executing module body. 2007-06-16 00: SQL Statement: ALTER TABLE "sphboard_post" ADD markup varchar(250) NULL Detected changes - Do you want to execute SQL Statements ? (yes,no): So if the SQL statement won't work with the database the user is currently running, he at least knows exactly what he is expected to change in his models. and he can stop automatic execution by simply entering 'no' here.
- changelog
- schema-evolution
HTTP headers view decorator
Decorator adding arbitrary HTTP headers to the response. This decorator adds HTTP headers specified in the argument (map), to the HTTPResponse returned by the function being decorated. Example: @headers({'Refresh': '10', 'X-Bender': 'Bite my shiny, metal ass!'}) def index(request): ....
- http
- view
- decorator
- headers
Natural language date/time form fields
Form fields use the dateutil module [http://labix.org/python-dateutil](http://labix.org/python-dateutil) to parse natural-language input for date and datetime fields. The callback function will replace all date and datetime fields automatically for form_for_model and form_for_instance. **Note**: by replacing the 'form_class' keyword argument instead of just returning the field itself you preserve the 'required' status of the field.
- newforms
- datetime
- date
3110 snippets posted so far.