Barry, it sounds like we are working different ends of the same problem. I haven't been that interested in solving the form generation problem, since I seem to always have a lot of fields that should not be available to any/all users. But you can check out my query-writer package. It is due for an upgrade, where I will make a few data model changes and scrap most of the admin ui (I think). I am planning on changing the tcl api so that procs named qw_* will be renamed to qw::*, but the url api will remain unchanged.
The biggest change will be that you should be able to create the pl code for the package with one tcl call, giving the name of the table to base the object on. I already have the function to go through pg and find all attributes, back to acs_objects that would apply to the object. Further api calls could add/subtract/modify the default pl code generation. Another big change will be that a lot of pl code will be replaced to use regular dml code. Updates can use a little pl (an is_object_p function) plus mostly dml, deletes might involve more pl. But updates are the big problem, being very inefficient in pl, where each attribute is updated separately, and then you need a separate function to nullify, or reset an attribute value.
The query-writer also works for non acs_objects as well.
Check out the trace function for attributes here.
I'm also experimenting with a table specification/generation idea that uses a language similar to xml, but far simplified. I figure having a db neutral method of table specification could speed up and regularize table code writing. I like having named constraints for every column constraint, and it is a lot faster do this automatically.
