This method allows you to define pre_save and post_save signal connections for your decorators in a little more clean way. Instead of calling `pre_save.connect(some_func, sender=MyModel)`, or perhaps `pre_save.connect(MyModel.some_static_func, sender=MyModel)`, you can simply define the pre_save method right on your model. The @autoconnect decorator will look for pre_save and post_save methods, and will convert them to static methods, with "self" being the instance of the model.
The middleware assigns a unique identifier for session. The session id doesn't depend of session or whatever else. It only need cookies to be turned on.
The session id is reassigned after client close a browser. Identifier of the session could be read from request: request.current_session_id.
You can setup name of the cookie in yours settings module (FLASH_SESSION_COOKIE_NAME).
request.current_session_id is lazy. It means the ID will be assigned and cookie will be returned to client after first usage.
Auto-incremented primary keys are the default in Django and they are supported natively in most databases but for anything more complex things are less trivial. DB sequences are not standard, may not be available and even if they are, they are typically limited to simple integer sequence generators. This snippet bypasses the problem by allowing arbitrary auto-generated keys in Python.
The implementation needs to determine whether an IntegrityError was raised because of a duplicate primary key. Unfortunately this information is not readily available, it can be found only by sniffing the DB-specific error code and string. The current version works for MySQL (5.1 at least); comments about how to determine this in other databases will be incorporated in the snippet.
These are template tags meant to support the construction of text in a random or seeded random (reproducible) way. Two tags are provided: `seed_randomization` and `any`.
Only seed the randomization if you wish to have the options generated the same way each time. Only necessary once per request, if done early enough in the rendering process.
Example without seeding:
<p>
{% any %}
One day
Once upon a time
In a galaxy far, far away
{% endany %}
a young foolish {% any %}programmer|lawyer|Jedi{% endany %}
{% any %}
set out
began his quest
ran screaming
{% endany %}
to pay his stupid tax.
</p>
# Possible outcomes:
<p>In a galaxy far, far away a young foolish lawyer set out to pay his stupid tax.</p>
<p>One day a young foolish programmer ran screaming to pay his stupid tax.</p>
Be sure to read the documentation in the code.
If you are like me and you find yourself often using M2M fields for tons of other on-model methods, in templates, and views alike, try using this quick and dirty caching. I show the use of a "through" model for the m2m, but that is purely optional. For example, let's say we need to do several different things with our list of beads, the old way is...
# views.py
necklace = Necklace.objects.get(id=1)
bead = Bead.objects.get(id=1)
if bead in necklace.beads.all():
# this bead is here!
# template necklace.html
{% for bead in necklace.beads.all %}
<li>{{ bead }}</li>
{% endfor %}
...which would hit the database twice. Instead, we do this:
# views.py
necklace = Necklace.objects.get(id=1)
bead = Bead.objects.get(id=1)
if bead in necklace.get_beads():
# this bead is here!
# template necklace.html
{% for bead in necklace.get_beads %}
<li>{{ bead }}</li>
{% endfor %}
Which only does one hit on the database. While we could have easily set the m2m query to a variable and passed it to the template to do the same thing, the great thing is how you can build extra methods on the model that use the m2m field but share the cache with anyone down the line using the same m2m field.
I'm by no means an expert, so if there is something here I've done foolishly, let me know.
*JsonWebService.jsonresponse
JsonWebService provides the property jsonresponse which marks the method it is applied to, and also serializes to json the response of the method.
*JsonWebService.urls
Scans the marked methods and build a urlpattern ready to use in urls.py
Add it to MIDDLEWARE_CLASSES and you will get request.current_view getting values like "connection.views.index" or "django.views.static.serve" - one example usage is to show different help text based on current view name.
EDIT: actually, you can use process_view middleware function where you automatically get current_view as first parameter.
This snippet is based on 928.
I've added the support to update a custom folder, using shell arguments.
It requires the argparse module.
You can install it with:
pip install argparse
Usage:
# Updates repositories in the specified <folder path>
# The default is the ./ folder
update_repos --path <folder path>
# List available options
update_repos -h
Alessandro Molari
The syndication documentation gives a very basic beginning to creating an iTunes Podcast Feed, but leaves a lot of work left to be figured out. This is a completed example. Because I needed to obtain the duration of the podcast file programmatically (not part of this code) I limit the podcast to mp3 files. If you want to obtain durations some other way you can set the mime_type in the same manner as the other properties.
This is what I'm using and should be plenty for you to customize from.
Simple logging decorator. Logs the function name along with the message.
`Jul 14 16:10:42 mtzion test_func: 1 two`
Define SYSLOG_FACILITY in settings.py.
import syslog
SYSLOG_FACILITY = syslog.LOG_LOCAL1
The new changelist supports clicking on a column header to order by that column, like iTunes. Unlike iTunes, which sorts by track number if you click the Artist or Album column header, it can only order by the column clicked on. By adding a property to my ModelAdmin, and subclassing ChangeList, I was able to make it also sort by track number when sorting by Artist or Album.
[Blog post](http://python-web.blogspot.com/2010/07/sorting-by-more-than-one-field-in-admin.html)
[Repository with full example](http://github.com/benatkin/tuneage)