Forms and Formcontroller

Creating forms in KARL3 is relatively easy. We’re using tools and approaches common to other Python web frameworks: ToscaWidgets, FormEncode, etc. More specifically, we’re not trying to do schema-driven, autogenerated, CRUD forms.

Current Plan

We currently do forms like this:

1. We define a form using TW (ToscaWidgets).

2) The forms are almost aways collections of the same, already-defined fields (title, text, privacy, etc.)

3) We have some custom widgets in Mako and some custom validators in FormEncode.

4) We have a thin concept called a “FormController”. It knows when a form was submitted, when a form was valid, and how to get/set content in bulk. (We hate that part.) Otherwise, everything else is stock TW and FormEncode.

5) View functions are responsible for instantiating a form, making a form controller, doing branching, and updating the model.

6. People can always ignore TW and just write HTML forms in their ZPT.

What We Don’t Like

• Performance. For whatever reason, TW is slow.

• Inscrutable. Chris spent four hours trying to do a relatively

  simple customization to a widget. Like so many frameworks, TW wants to do a lot. Making it somewhat challenging to dive in. Its documentation story isn’t as good as it looked at first. Finally, Mako has a certain “designed by the Perl guys” kind of attractiveness.

• Hard to debug. When something goes wrong, it isn’t always clear

  where to go. Related to other irritants listed here.

• Pay for what you eat. We’re working hard in KARL3 to toss out

  hammer factory factory factories. We don’t really need the pluggability and features that we’re paying the price for in TW.

First Attempt at Slimfast

Over Christmas we did some work at ripping out TW. For the most part, we got far enough to know what we want (described below). However, we don’t have time to convert everything, including the tests and widgets, nor finish the use cases listed below.

In a nutshell, it looked like this:

1. Keep FormEncode. In fact, move closer to it (use its concept of a Schema.)
2. Throw out the idea of pluggable “widgets”. Instead, just have HTML in a ZPT that arranges the form elements, labels, hints, CSS styling, etc. We don’t need a thousand custimization points exposed in Python.
3. Instead, focus on “fields”. These are a configured widget, such as title. Have ZPT macros that make it easy to put the form control into a form.
4. Render the form HTML, then use lxml.html and its form-filling conveniences to hack the markup.
5. Have the form machinery be blissfully ignorant of where data comes from, whether it is transient data (from a form invalidation), model data (on an edit form), or default data on an add form (most likely, just embedded into the HTML.)
6. Keep the model, view, and form at arms’ length from each other. All the frameworks want to “help”. For example, you hand it a model and the form controller pulls data out of it, or shoves data into it. Bleh. There be dragons.

In our first cut, we went from around 38 requests/second to around 300 requests per second on an add form. Debuggability and test ability went up by a similar factor.