Like most young adults, my views on religion have evolved as I have grown. As mortals, we all face death. If you’re going to die someday, you’d better be darn sure to file your paperwork with the appropriate deity, and file it early. I doubt the Almighty One would look very favorably on someone who hurriedly shoved their application in the mail in hopes that the Holy Office receives it before the deadline arrives.

Some background: I was raised Catholic, but I’m not particularly attached to Catholicism; I prefer to consider myself a Christian. I’m politically liberal, which informs my distaste for the whole Baptist/Evangelical/Pentecostal scene. (I once received a pamphlet from someone at Grace Church informing me that as a Catholic, I was doomed to hell. Duly noted.)

While I haven’t lost faith, I haven’t really embraced it either.

I want to find God. I want to be less apathetic about Christianity.

Two things push me away:

1. I’ve seen many people present themselves as Christian (as above) while believing and proclaiming things that strike me as profoundly un-Christian: denouncing other Christian denominations, interpreting the Bible hyper-literally, advocating creationism, and presenting religion as the basis for ultra-conservatism.

2. As a programmer, I think about everything logically. There is no scientific proof that God exists. The Vulcan in me would dismiss religion because of its disconnection with science. Creationism is clearly false, ergo people who interpret the Bible literally are wrong. Without evidence for God, my belief fades.

In order to really strengthen my belief in God, I need to account for these two conundrums. I suspect that I can reconcile the first by admitting that religious institutions aren’t really God’s creation, but man’s, and by recognizing that people who claim to follow Jesus aren’t necessarily on the right path either. I’ll resolve my second issue if I can find enough rational thought and evidence for God to quell my logic-based doubt.

Those are my two prominent unanswered doubts, and they aren’t the kind of questions that can be answered easily. I may have to grapple with them for a while. I’ll have to seek answers, since I can’t find the solutions in my own mind.

Donald Miller gave a presentation at Gateway Church last fall. He said something that really hit hard:

We are a part of a huge story: The Epic of Creation, which is told in the Bible through many stories and teachings. Human Life is not the climax of the story, though: We are in act two. The Bible didn’t end when Jesus rose from the dead.

Don explained that a story is “a sense-making device, in which a character wants something and overcomes conflict to get it.” Every story ever written or told follows that pattern; there must be conflict in order for there to be resolution.

The part that struck me was the way he described the Bible as an epic story. Not just any epic, mind you. The epic. The most magnificent story ever told, and ever to be told.

There’s something in that nugget of wisdom that I can’t ignore. It makes everything seem so right, like the pieces of a puzzle finally clicking into place to reveal a masterpiece.

I asked for, and received, a NLT Bible for Christmas. I already had a Bible, but I wanted one that is willing to eschew traditional wording in favor of a tone that better represents the meaning of passages rather than their literal translation.

The next step in my search for God: I must read The Epic.

I have considered writing about my findings, though I haven’t yet decided. The Epic of Creation isn’t something I intend to speed through, after all. It must be given a fair, thorough read.

I hope that, like a good book, I will one day finish the last page, close the book, and find myself filled with clarity and understanding.

Realistically, one reading probably won’t leave me questionless. The Epic is an instruction manual for life, the universe, and everything. As a man, I don’t always read instructions. But when you can’t figure it out yourself, what do they always say?

Read the manual.

Windows 7 marks the second full-on release of Windows that I have never used. Ask me to help you with your post-Windows-XP computer, and I will perform elaborate magic tricks:

via XKCD

Fortunately, those antics can solve just about any computer problem nowadays. As long as I can find the right menu or control panel option, we’re all set.

I knew Windows XP intimately; I could change networking settings or customize anything without skipping a beat. But I switched to the Mac never having used Vista.

Now, it only looks like I know what I’m doing in Windows because I click through each option very quickly. I haven’t the slightest idea how to change your display resolution, but if I don’t see it in one control panel, I’ll jump to the next one before it even finishes loading.

Ah, now you know my secret.

I was a little put off with the realization that I no longer know what features Windows supports, what applications and utilities are most useful on Windows, and I haven’t any idea how to use the latest version of the Office suite. Windows was all I knew, frankly; we were together since Windows 3.1. But I’ve moved on.

All is not lost, though: For most people, Windows is irrelevant. Their browser matters. Then again, they don’t care about their browser either. But I know browsers. I can whip out an installation of Chrome faster than Windows boots.

These days, browsers and I hang out an awful lot. I think we have a bright future together. So long, Windows.

Sometimes musicians need a little honest feedback:

Download a printable version here.

You should use Django Forms with your Pylons application. In fact, I recommend it for every Pylons site you create.

Django developers rarely use third-party components like SQLAlchemy or Mako;¹ Pylons developers don’t often use Django components either. Both SQLAlchemy and Mako are great components: flexible, powerful, and fast. (If Django was created later, it might have used them instead.)

Form handling is another story, though. Pylons’ @validate decorator is a mess and has needed an overhaul for years, but no clear fix has emerged. A decorator is the wrong approach; it’s too inflexible. But manually working with FormEncode and htmlfill can be painfully cumbersome and verbose. While FormEncode is flexible, it isn’t elegant. Likewise, htmlfill can get in the way if you aren’t careful.

FormEncode is like playdough. It’s very flexible, but it’s a little messy. And you’d better not get any on the carpet.

I spent many hours working through solutions to this problem. I looked at alternatives like FormBuild, FormAlchemy, and ToscaWidgets; I even tried to build my own. Nothing stood out as a clean, elegant solution.

I turned to an unexpected place for salvation: I believe django.forms is the best option for working with forms in Pylons, hands-down.

Believe me, I was surprised too. Especially in light of that whole conceptual integrity debacle.

Why Django Forms? It’s widely considered to be a clean, flexible way to handle form validation and processing. It’s used by the largest Python web framework around with few complaints and much praise. And I know that it will be around for a long time, with lots of attention paid to backward compatibility.

I was concerned that it would be difficult to use just the forms part of Django. Fortunately, Django developers did a good job sandboxing the forms library from the rest of the Django suite. Surprisingly, django.forms works quite well out of the box; a few monkeypatches solidify the few areas that needed a little tidying.

This is good stuff, folks.

Simple Instructions

All of the tweaks needed for django.forms to work are included in a module named forms.py that you can obtain on GitHub.² That module is intended to be a drop-in replacement for the django.forms module. (It does not replace your Django installation; you’ll just import that module instead. You must have Django installed first.)

Copy that downloaded forms.py module into your Pylons project (perhaps in your lib directory) and import that instead of django.forms. That’s it. The Django form documentation will take you the rest of the way.

Integration

The forms module I linked to above includes all of the following fixes; only read this section if you are interested in the technical details of what needed to be patched.

1. First, django.conf.settings.configure() was called (once and only once).
2. Django uses a function called mark_safe to escape HTML; that function was patched to mark strings with a WebHelpers literal as well.
3. forms.widgets.SelectMultiple was modified to support Paste’s MultiDict, as noted in this Django ticket.
4. Django’s FileField was patched to handle cgi.FieldStorage, which Pylons uses to upload forms.

That’s it. With those fixes, Django Forms work without a hitch.

You’re probably wondering about SQLAlchemy models. Django’s ModelForm obviously won’t work in Pylons without extensive modifications, but I’ve included a few helper utilities in forms.py that make model validation really easy. More on models below.

The Django Forms Workflow

Rather than a clunky @validate decorator, Django uses a simple idiom in which form processing and form display are included in the same action. This idiom keeps your controller code simple and clear, and that’s one of the reasons I liked Django’s form approach. Here’s how you would use the Django idiom in Pylons:

class CommentForm(forms.Form):
    name = forms.CharField()
    email = forms.EmailField()
    text = forms.CharField(widget=forms.Textarea())

# in your controller
def add_comment(self):

    if request.method == 'POST':
        c.form = CommentForm(request.POST)
        if c.form.is_valid():
            comment = Comment()
            comment.name = c.form.cleaned_data['name']
            comment.email = c.form.cleaned_data['email']
            comment.text = c.form.cleaned_data['text']
    else:
        c.form = CommentForm()

    return render('/add_comment.html')

(The /add_comment.html template would render the form itself, e.g. via ${c.form}.)³

Simple, eh? No decorator nonsense. Just process the form in that action and be done with it. That code works perfectly fine in Pylons. The editing workflow is similarly easy:

# in your controller
def edit_comment(self, id):
    c.comment = Session.query(Comments).get(id)

    if request.method == 'POST':
        c.form = CommentForm(request.POST)
        if c.form.is_valid():
            # update the model's fields with the validated form data
            forms.update_model(c.comment, c.form.cleaned_data)
    else:
        # Fill the form with the existing comment's information.
        c.form = CommentForm(initial=forms.model_to_dict(c.comment))

    return render('/edit_comment.html')

Note the use of forms.update_model() and forms.model_to_dict(); I included these two utility functions in lieu of a complete ModelForm replacement.

forms.update_model(model, data, include=None, exclude=None) lets you quickly assign validated form data to your model.

forms.model_to_dict(*items, include=None, exclude=None) transforms a model into a dictionary that you could pass to Form‘s initial keyword argument; multiple items are merged together into the result so that you can override specific initial fields yourself:

>>> c.comment.name
'Steve Jobs'
>>> forms.model_to_dict(c.comment, 
...                     {'name': 'John Doe', 'foo': 'bar'},
...                     exclude=['email'])
{'name': 'John Doe', 'foo': 'bar', 'text': '...'}

With forms.model_to_dict() and forms.update_model(), it’s trivial to work with SQLAlchemy models with forms. It’s a touch more verbose than Django’s ModelForm, but it’s explicit, simple, and easy to understand. View the source for more examples.

What about FormEncode?

As I mentioned above, a killer aspect of Django’s forms is the idiom they use to process requests. But Pylons isn’t going to add a dependency on Django just so that developers can use django.forms. What if you would rather use FormEncode?

You’re in luck. You can still use Django’s form processing idiom with FormEncode. I would argue that it should replace @validate as the recommended way to process forms.

Here’s the code, using the forms.FormEncodeForm class:

class CommentForm(forms.FormEncodeForm):
    html = render('/edit_comment_form.html') # <-- Note This

    name = formencode.validators.String(min=10)
    email = formencode.validators.Email()
    text = formencode.validators.String()

This idiom binds the form’s HTML template directly to the Form instance. You can either provide html as a class variable (as above), or as a keyword to FormEncodeForm.__init__. That way, the Form class can render itself just like Django’s forms do.

Here’s the controller code for a FormEncode-based form:

# in your controller
def edit_comment(self, id):
    c.comment = Session.query(Comments).get(id)

    if request.method == 'POST':
        c.form = CommentForm(request.POST)
        if c.form.is_valid():
            # update the model's fields with the validated form data
            forms.update_model(c.comment, c.form.cleaned_data)
    else:
        # Fill the form with the existing comment's information.
        c.form = CommentForm(initial=forms.model_to_dict(c.comment))

    return render('/edit_comment.html')

Look familiar? It should. It’s exactly the same as the code you saw earlier that used Django-style forms.Form.

Let me say that again: Form processing is exactly the same.

Both forms.Form (Django-style) and forms.FormEncodeForm (FormEncode-based) use the same idiom for controller code. The FormEncodeForm class handles htmlfill behind the scenes. You provide the form HTML and the schema, and it just works. (With either of those classes, you’d render the form itself using code like ${c.form} within your page template, as explained in the Django documentation.)

Where does that leave us?

I don’t know about you, but I’ll tell you where it leaves me: I use Django’s Forms with Pylons, and I couldn’t be more pleased.

If I didn’t convince you to switch to Django Forms and you aren’t happy with the @validate decorator, consider looking at the FormEncodeForm class. It’s only a hundred lines or so, and that workflow works much more smoothly than @validate.

If you aren’t sure, or if my explanations were unclear, just go look at the source itself. It’s only around 300 lines long, and mostly docstrings; it should be easy to grasp if you understand a little about Django and Pylons.

Kudos to the Django team for decoupling most of the forms library from the rest of Django. Ideally it would be a separate library so as to not require Django in its entirety, but I’ll take what I can get.

This solution blindsided me, and I’m still shocked that it was that easy. A day or so of coding, and my form handling issues are done.

Django Forms. That was the ingredient I was missing for so long.

Pylons + SQLAlchemy + Mako + Django Forms.

That’s a winning combination.