This is my blog, there are many others like it but this one is mine.

Using Pyramid with Deform to Edit/Create records in SQLAlchemy backed database

While working with Pyramid it was worth taking a good look at deform. During my brief look before, the one thing that appeared to be missing was a method to quickly integrate with SQLAlchemy backed data. For a handful of forms, manually creating the appstruct to be passed to the Form wouldn’t be difficult, but, for some more significant applications, it could be quite cumbersome. The following is a one page application that allows you to create a new user, or, edit an existing user by specifying the userid in the URL. The two pieces that do the real work are record_to_appstruct and merge_session_with_post. record_to_appstruct takes the class returned from SQLAlchemy and converts it to an appstruct that deform likes. Once we get the validated data, we merge the record with the post items using merge_session_with_post, merge the record and present a screen with the post data.

This is more a proof of concept, but, works well enough that we were able to convert quite a few forms and work more closely with Deform and Pyramid as we do more development.

This entry was posted
on Monday, November 8th, 2010 at 3:51 am and is filed under Framework.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.

Hi,
As the number one site on Google for Pyramid and Deform… I am very new to website development in Python (or actually anything more than Notepad) and am working with Pyramid because Python is my favorite language. I’m struggling with how to handle forms and would like to know if you think it is a viable approach for people well^n below Chris M’s level? I panicked when I read that I would have to convert all of the Chameleon templates to Mako, and while I’ve started building my own Mako template library, my head exploded when I looked at the Chameleon syntax…

If not Deform, do you have a recommendation? My next choice would probably be pyramid_simpleform, I found a bunch of errors when I tried it but Dan Jacob fixed them immediately. After that it looks like doing it myself with Formencode, et. al.

I use mako templating and use deform. Unless you’re changing the style of the deform templates, it will render its portion and insert it into your mako (or jinja2) template without you needing to change the forms. If you want to modify the actual look of the forms, you would need to use Chameleon or Mako. I have contemplated converting the forms over to mako and emulating the TableForm layout that ToscaWidgets uses which provides a more compact data entry screen. If you’re happy with the List Form layout, you can just modify the .css that is used to style it differently without having to touch any of the Chameleon templates.

Most of the form libraries are very disconnected from the SQLAlchemy schema, which means you have a lot of double entry. If your data entry isn’t tightly tied to your database schema, then deform or simpleform would probably be my recommendation. If you do a lot of data entry that is highly coupled to your database, you might also take a look at http://docs.formalchemy.org/pyramid_formalchemy/ which uses your SQLAlchemy schema to generate forms. You can of course specify included or omitted fields.

Thanks, I’ll take a look at FormalAlchemy. I used ToscaWidgets when I was working with TG2.1 and one of my concerns is that when something stopped working (Datepicker as I recall) I had no good way to troubleshoot it since I didn’t understand all the interactions. After posting this I went back to pyramid_simpleforms, found some more documentation issues and while I don’t appear to have it totally working it seems simple enough that I have a chance of troubleshooting on my own. With that simplicity probably comes a need to do more work with the other elements of putting together a page but I need to learn sometime…

With deform it seems there is always some code duplication between the colander schema definition and the class that assembles the data from the database. In the case of SQLAlchemy have you come across any other pattern to have a more “DRYer” solution? I’m tempted to look into something related with the SQLAlchemy mapper and creating colander schemas imperatively. Have you considered those?

Deform was inspired by Formish and both are written to use object stores – like ZODB, so, they write the appstruct right to their schemaless storage with their primary key. Once you move to a schema based backend, you have to do some manipulation. If you’re looking to tie your forms more closely to SQLAlchemy, FormAlchemy is very good and well integrated with Pyramid. Form Schema definitions can be as few as 3-4 lines specifying the submit action text, included fields and the class name.

I thought about using mappers with Deform, but, hadn’t had the chance. With the current system, related rows that use Integers as IDs cause a problem, but I haven’t had time to delve into that.

That is a good point, and would work properly with the password verification field with deform. Since the code hack was written a two days after Pyramid was released, it was just a quick hack to migrate some Pylons code and to try Deform.