Then, all you need is a simple twistd wrapper:

from twisted.scripts import twistd
from pyutils import autoreload

autoreload.main(twistd.run)

[1] http://twistedmatrix.com/trac/ticket/4072

• Nested Set trees.
• A register() call is used to set things up; it ads the necessary fields to the model.
• A tree model still has a foreign key to itself. This is the API you use to manage the tree. Signals are used that the hidden tree fields are updated when the parent ForeignKey changes. No add_child() required.
• Using the foreign key to self means that deletion is handled automatically be Django and/or the database. The other libraries need to implement a custom Queryset subclass to handle deletes.

django-treebeard

• Has an awesome name.
• In addition to the common Nested Set/MPTT approach, supports two other tree implementations. Materialized Path in particular is interesting.
• You inherit your models from abstract base classes, which I like.
• The tree has to be managed manually, that is, there are specific APIs like add_child() you have to call.
• Unfortunately, those APIs are classmethods on the model rather than the Django-way, putting them into the model manager.

django-easy-tree

• Apparently a fork of django-treebeard, but only supports Nested Set trees.
• But has a prettier API that fits very well into Django: Nicer class names, properly puts methods into the manager when they belong there, options are specified inside "Meta" rather than on the model itself.
• Has an interesting concept of validators. Included is a SingleRootAllowedValidator.
• No tests!

Clearly, somebody needs to write a django-treebeard that uses the django-easy-tree API design and django-mptt's signal approach.

Now, one obvious things to do is using an in-memory SQLite database for testing purposes. I've tried that at times, but ultimately, various MySQL-specific stuff and raw SQL queries always made this an unsatisfying experience.

I've now finally realized that there is an easy solution, and I'm perplexed it didn't occur to me earlier (maybe Linux, to which I've recently switched, just puts these kinds of options closer to one's grasp). And it really is pretty straightforward: Mount a tmpfs, run a second MySQL instance on a different socket/port using this mount as a data dir, and tell Django to use it.

I've put shell script that I'm using on github.

You might want to customize the location of the data directory or the bind options, then simply do:

sudo ./mysqld-ram.sh

and when you're done, shutdown with Ctrl+C.

The tables which previously took a minute to setup, now only need two and a half seconds. It even cuts the runtime of the actual tests, which were already using transaction-rollback before, in half. Not surprisingly, I notice that my motivation to actually write tests and keep them up-to-date has noticeably improved.

It contains stuff like /Description/TreatAsSystem, /Description/GuidCache and a whole bunch of guids under /Objects. Presumably, the actually interesting data is there, but unfortunately, it's all binary.

A guy named Geoff Chapell has some info on what it all might mean.

ssh-done() {
        setterm -term linux -inversescreen off;
}
ssh() {
        setterm -term linux -inversescreen on;
        /usr/bin/env ssh $*;
        ssh-done;
}

The reason why ssh-done is exposed as a separate function is that when ending ssh through Ctrl+C (for example, while at the password prompt), this gives you the ability to manually reset the terminal to normal again.

setterm in theory would also allow you to manually select a foreground and background color, though this didn't work to well for me; in particular, it broke in various cases when commands tried to colorize their own output.

Totally awesome would be the ability to script gnome-terminal to switch the profile, but this doesn't seem to exist yet.

Here's what you need:

• python-dateutil, which provides the parser.
• This file, which implements DateTimeField and DateField form field classes which use python-dateutil to process the input.

With that available, the actual code is quite simple:

from djutils.forms.fields import formfield_callback

class YourForm(ModelForm):
    formfield_callback = formfield_callback
    class Meta:
        model = YourModel

The formfield_callback will ensure that for every DateField or DateTimeField that your model has, the appropriate form field with dateutil-parsing support will be generated.

Of course, you can use these fields manually as well:

from django import forms
from djutils.forms.fields import DateField

class MyForm(forms.Form):
    std_date = forms.DateField() # < - Uses the standard DateField
    parsed_date = DateField()  # <- Uses the custom DateField

This should work well enough; we can now put something like 8th of January into the form, and it'll be parsed into the correct date.

"8th of January"? My site is in German! Fortunately, while not supporting it out of the box, python-dateutil is flexible enough to allow for internationalization as well. You need to get:

• Yet another file, which adds support for German date strings to python-dateutil (i.e. "Janauar", "Montag", ....). If you need to support a different language, you can use that file as a template.

The way internationalization is done with python-dateutil is that you implement a parserinfo class for a given language. We need to tell our custom form fields to use the German parserinfo provided by the file above:

from djutils.forms.fields import get_formfield_for
from pyutils.date import GermanParserInfo

class YourForm(ModelForm):
    def formfield_callback(field):
         # If it's a date-related field, get one of our custom form fields
         result = get_formfield_for(field, parserinfo=GermanParserInfo())
         # Otherwise, use the default form field.
         return result or field.formfield()
    class Meta:
        model = YourModel

That's basically it. You might want to create a base form class that you can inherit from for DRY purposes.

By the way, my module containing the German parser info also has a MultiParserInfo helper that may be useful to some:

parserinfo=MultiParserInfo(parsers=[GermanParserInfo()])

This will give you a parser that supports both German date names, and the original English date names as a fallback. If you need to support even more languages, you could too:

parserinfo=MultiParserInfo(parsers=[GermanParserInfo(), FrenchParserInfo()])

It turns out that apart from your normal "From" sender, an email message also has an envelope sender specified in the Return-Path header. The first is considered to be the author, the second refers to who is responsible for actually sending the message.

So my site sent those contact form emails to me using as the sender whatever the user specified as his email address in the form - in both the From and Return-Path path fields. Whenever the user's email domain had SPF records installed, the validation would run the user's email against my mail servers and thus obviously fail.

The solution then is to use as the Return-Path an address of your own. How to do this in Django? It's really simple, but totally non-obvious. This is per Ticket 9214 and Changeset 9842 (so you need at least 1.1).

connection = SMTPConnection(fail_silently=fail_silently)
headers = {'From': 'users@email.address'}  # From-header
from_email = 'bounce@mysite.com'           # Return-Path header
EmailMessage(subject, message, from_email, recipient_list,
                   connection=connection, headers=headers).send()

Note that we need to work with ``EmailMessage`` directly - django.core.mail.send_mail doesn't provide an option for custom headers.

If you are using django-contact-form, it unfortunately doesn't support custom headers out of the box either, so you need to apply a patch. Then, the following should work:

class MyContactForm(AkismetContactForm):
    def __init__(self, *args, **kwargs):
        super(self.__class__, self).__init__(*args, **kwargs)
            self.subject = "Contact Form"
            self.template_name = "site/pages/contact_email.txt"
            # Return-Path header, e.g. bounce@mysite.com
            self.from_email = settings.DEFAULT_FROM_EMAIL
            # From-header
            self.headers = \
                lambda: {'From': "%s < %s>" %
                    (self.cleaned_data['name'], self.cleaned_data['email'])}

Unfortunately, both TextView and the Linkify utility it uses basically hardcode URL click handling to Intents, by way of the URLSpans they create. What if we want the link to affect something within your own Activity, say, display a dialog, or enable a filter?

For example, in Autostarts, if the user's filters cause the application list to be empty, I wanted to display an explanatory message, and provide a quick and easy way for the user to rectify the situation, i.e. lead him towards the filter selection dialog. Making the whole text clickable is hard to get right visually, and I didn't like the idea of a button too much. A link within the text seemed perfect.

Now, we could just use a custom URL scheme of course, and register our Activity to handle Intents for that scheme, but that seemed much too heavy, if not hacky. Why shouldn't we be able to just hook up an onClick handler?

As mentioned, URLSpan doesn't allow us to change the way it handles clicks (it always sends off an Intent), but we can create a subclass:

static class InternalURLSpan extends ClickableSpan {
	OnClickListener mListener;

	public InternalURLSpan(OnClickListener listener) {
		mListener = listener;
	}

	@Override
	public void onClick(View widget) {
		mListener.onClick(widget);
	}
}

That looks pretty decent. Actually using that class it is more though. There is no way to tell TextView or Linkify to use our custom span. In fact, Linkify actually has a method (applyLink) that would be nearly perfect to override, but declares it final.

So, we end up having to generate the spans manually; note nice, but hey, it works.

SpannableString f = new SpannableString("....")
f.setSpan(new InternalURLSpan(new OnClickListener() {
        public void onClick(View v) {
            showDialog(DIALOG_VIEW_OPTIONS);
        }
    }), x, y, Spanned.SPAN_EXCLUSIVE_EXCLUSIVE);

We probably also want the user to jump to your link my moving the focus (e.g. using the trackball), which we can do by setting the proper movement method:

MovementMethod m = emptyText.getMovementMethod();
if ((m == null) || !(m instanceof LinkMovementMethod)) {
    if (textView.getLinksClickable()) {
        textView.setMovementMethod(LinkMovementMethod.getInstance());
    }
}

[via]