A simple template filter for parsing tweets (linking @ replies, hashtages and standard URLs whilst stripping out links to yFrog and TwitPic images), and two simple tags for displaying the yFrog and TwitPic images linked to in tweets.
If you put the snippet in a file called tweets.py, as long as it lives in an app's templatetags directory, you should be able to do the following (where `text` refers to the text of a tweet):
{% load twitter %}
<p>{{ text|tweet }}</p>
{% yfrog_images text 1 'fancybox' %}
{% twitpic_images text 1 'fancybox' %}
The first argument in the two tags controls how many images to render. Set this to -1 for an unlimited number, per tweet.
Thumbnail images are displayed, and you can specify the class that is applied to the `<a>` tags rendered. Here I've used 'fancybox', and I would normally include jQuery code to turn the images inside the `<a>` tags into lightboxes.
When you want to save integers to the db, you usually have the choice between 16-, 32- and 64-bit Integers (also 8- and 24-bit for MySQL). If that doesn't fit your needs and you want to use your db-memory more efficient, this field might be handy to you.
Imagine you have 3 numbers, but need only 10 bit to encode each (i.e. from 0 to 1000). Instead of creating 3 smallint-fields (48 bit), you can create one 'ByteSplitterField' which implements 3 'subfields' and automatically encodes them inside a 32 bit integer. You don't have to take care how each 10-bit chunk is encoded into the 32-bit integer, it's all handled by the field (see also field's description).
Additionally, the Field offers opportunity to use decimal_places for each of your subfields. These are 'binary decimal places', meaning the integer-content is automatically divided by 2, 4, 8, etc. when you fetch the value from the field.
You can also specify how values are rounded ('round' parameter) and what happens when you try to save a value out of range ('overflow' parameter)
Not implemented (maybe in the future if I should need it sometime):
* signed values. All values are positive right now!
* real (10-based) decimal places (actually you could probably directly use DecimalFields here)
* further space optimization, i.e. saving into CharField that's length can be chosen byte-wise
- model
- db
- database
- field
- custom
- custom-model-field
- IntegerField
- multibit-field
- model-field