I'm using the Django Feeds Framework and it's really nice, very intuitive and easy to use. But, I think there is a problem when creating links to feeds in HTML.
For example:
<link rel="alternate" type="application/rss+xml" title="{{ feed_title }}" href="{{ url_of_feed }}" />
Link's `HREF` attribute can be easily found out, just use `reverse()`
But, what about the `TITLE` attribute? Where the template engine should look for this? Even more, what if the feed is build up dinamically and the title depends on parameters (like [this](http://docs.djangoproject.com/en/dev/ref/contrib/syndication/#a-complex-example))?
This is the solution I came up with. However, as you can see, there is some caveats:
* Requires Django 1.2 Class Feeds, don't know exactly how to do this with the old way of feeds.
* If the feed class uses the request object, the `request` [context processor](http://docs.djangoproject.com/en/dev/ref/templates/api/#django-core-context-processors-request) must be configured, since `None` is passed if it isn't present in the context.
* There's an oddity with Feed.__get_dynamic_attr(). The Feed subclass instance doesn't have this method; instead, it appears with another name. Don't know how to figure the name out at runtime...
I've posted this problem on [StackOverflow](http://stackoverflow.com/questions/2784659/django-dry-feeds), but didn't get a better answer.
- Feeds DRY templatetag HTML LINK
I found my self doing data migration for a client, and also found that their old system (CSV) had 4 text fields that were 2 to 4MB each and after about 2 minutes of hammering the mysql server as I was parsing this and trying to insert the data the server would drop all connections. In my testing I found that if I didnt send those 4 fields the mysql server was happy to let me migrate all my data all (240GB of it). So I started thinking, "I should just store these fields compress anyways, a little over head to render the data, but thats fine by me."
So thus was born a CompressedTextField. It bz2 compresses the contents then does a base64 encode to play nice with the server storage of text fields. Once I started using this my data migration, though a bit slower then without the field data, ran along all happy.
- text
- model
- field
- compress