I’m not a big fan of user interfaces that exist primarily to create and update database tables.
I think it’s because I came to programming long before I learned anything about databases. In my mind, a database is a back end tool, not something to be exposed to the user. Using an automatic tool to get data from the user and populate a database table from that data seems like giving up some sort of control over the whole process.
Web2py provides three basic ways to get info from the user and do something with it.
FORM
The FORM command allows you to build a form that gets passed to the view and displayed. In the controller, you have a simple if statement that you use to say what happens if the form is submitted by the user. This matches the way I think…the user submits data, then I do something with it.
Unfortunately, there doesn’t seem to be much customization in the way you can display a FORM generated form in the view. You get a pretty standard display.
If you want a customized form, you use SQLFORMs. Tip: look at using SQLFORM.factory to get the same effect as FORM, but with customization included.
SLQFORM
SQLFORM is designed to generate a form tied to a model. The form might be used to create a new record for the model, or to update an existing record.
SQLFORM does an awful lot for you. On the one hand, that’s part of what I’m not comfortable about. On the other hand, it takes care of creating drop down lists for foreign keys, and you can customize the appearance of the form on the view as much as you’d like.
You can also tell SQLFORM to generate the form, but to not actually update the database, in case you (like me) prefer to keep control over that end of things.
Crud
Crud is a layer on top of SQLFORM that further simplifies code, but also takes more control away. I can work with SQLFORM, but Crud seems too big a step in the wrong direction for me.
Could be that I’m just not oriented toward writing database applications, so my models aren’t written in a way that would cooperate nicely with Crud.
Which One?
The way I have my models designed, and the way I intend to work with them, SQLFORM with database I/O disabled will work best for me for creating most of the records in the database.
SQLFORM with database I/O enabled will probably work fine for updating records.
I’ll follow with some posts on using SQLFORM with database I/O disabled.