Forum OpenACS Development: Form generator for OpenACS4 / PostgreSQL

I just uploaded a tool I wrote called formwizard to see if anyone else finds it useful.

https://openacs.org/new-file-storage/one-file.tcl? file_id=334

I wrote the formwizard tool to help me create a web UI for some complicated client databases with dozens of tables and hundreds of columns. In the process I learned a lot about the OpenACS4 templating system's approach to forms, which I've always avoided learning about before because the API looked yucky. I hope that other people will find that formwizard provides a gentle slope to using ATS forms.

Formwizard is a code generator. It gives you an almost-ready-to-use page for adding and editing rows in a table that you specify. It gets the table information it uses by querying the PostgreSQL system catalogs. It wouldn't be hard to make an Oracle version.

The most important characteristic of this approach is unlimited flexibility. If you don't like the decisions the code generator made, you can change the results all you want. Using formwizard simply provides you with over 100 lines of boilerplate code, customized to the table you're working with. You can put the page wherever you want in your page flow. You're free to customize the form elements in whatever tricky way you want. Some of the things you'll probably want to do are:

• add some code to populate a select element with the results of a database query
• if you don't like the "Yes/No" approach to booleans, change them to checkboxes
• if the basic DML insert/update isn't good enough for you, change it to call stored procedures instead
• choose your own text or textarea sizes
• add section names
• modify the "standard" form template to look good on your website

Here are some highlights of what formwizard does for you:

• DB not null -> ATS "-optional" validation
• DB check constraint -> ATS select element with options parsed from check constraint
• DB integer -> ATS integer validation
• DB date,timestamp,time -> ATS date widget
• DB boolean -> Yes/No select
• DB primary key -> ATS "hidden" form element and the so-called doubleclick protection

I might overlook some of these things if I were writing the form by hand. I'm looking forward to better quality and consistency with the auto generated forms.

Please let me know if you can suggest any improvements or if you identify any bugs.

Thanks Don. The generated code works great for plain old database tables that are not ACS objects. That's what I'm working with at the moment, and that's what the insert and update statements are intended for. I don't think this tool will encourage people to ignore the PL/SQL API; they'd have to go out of their way to do that. If used against a typical OpenACS table, the default DML code will fail when trying to insert the table's primary key, since no corresponding row exists in acs_objects.

A different version of this tool could be produced that was more directly helpful in the effort to revamp the OpenACS UI. But it couldn't help you very much with the difficult task of figuring out the positional parameters in each API call, since as you say, the API for every object type is slightly different.

I followed the example of all the packages I could find that use ATS forms (like photo-album) and didn't attempt to do any validation of user input with ad_page_contract. That gets done by the template::element calls. I'm pretty happy with the way that validation errors get reported inline with the form.

Ahh, I see, Luke, this makes perfect sense with non-objects.

I'll have to take a look ... yes, avoiding ad_page_contract is unfortunately the right thing to do (until we figure out how to integrate form building with ad_page_contract, there's no reason we can't).  "self-submission" and a single form to create and edit get messy but have the advantage of only requiring one set of "element" calls to be generated.  So if you want to change the form you only have to edit one piece of code to do it.

But it does get messy.  A tool like this can help and integration with ad_page_contract would (*will*!) help, too.

Tom ... let's wait until after beta, at least, to put your package in?