Wizard generated Master-Detail form issues

Question

The wizard-generated master/detail forms have several severe usability issues when the "Choose Layout" option is set to "Builder master detail with: edit detail as tabular form on same page".
Some of these issues are:
- The form has two Apply Changes buttons, one to save the master row and one to save the detail row. Users find this very confusing. If you save the master row changes, any changes to the detail rows are lost and vice versa.
- The form has two Delete buttons, one to delete the master row and one to delete the checked detail rows. Users find this confusins also. Clicking the lower delete button discards any other changes that were made.
- The Add Row button also discards any other changes that were made.
The first two issues are easily fixed. With a few simple changes to the generated page, I can make it so there is a single "Apply Changes" button that 1) saves any changes to the master row, 2) saves any changes to detail rows and 3) deletes any checked detail rows.
I cannot figure out how to solve the third issue (that the add row button discards any changes). I can make it so the "Add Row" button saves the changes, but this isn't user friendly either; I don't think any changes should be comitted unless the user specifically presses 'Apply Changes'.
So far, I thought of several ways to possibly fix this but can't get any of them to work. Some of the ideas were:
1. The 'Add Row' button could run the automatic row processing and MRU processes, but not do a commit untill/unless Apply Changes is pressed. I don't think this is feasible because http is stateless and connection pooling may be used, so we can't have a transaction that spans http requests.
2. Move the Add Row process to page rendering so that the detail table always has an empty "add row" row thereby making the Add Row button unnecessary. I tried this, but it looks like the add row process was designed to run during the page processing, not during rendering, and it fails with a divide by 0 error when it is run during page rendering.
3. Use client-side DHTML (instead of the HTML DB add row process) to add an empty row to the html table (i.e. add row button does not do a submit, it is handled entirely on the client). I tried this, but the MRU process fails because it doesn't expect the added row.
If anyone has any other ideas on how to fix this problem, they would be greatly appreciated.
HTML DB solves this problem in the SQL workshop create table wizard.
In HTML DB 1.6, the "Add Column" button does a submit but somehow saves any changes that were entered.
In HTML DB 2.0 beta, client-side DHTML is used (my approach 3 above).
Can someone from Oracle share how the HTML DB create table wizard solves this problem?

Answer 1

Eric,
Thanks for your feedback. I’ll add your suggestions to our list of tabular form enhancement request.
The wizard generates a regular form for the master record and a tabular form for the detail records. As you pointed out, it’s quite easy to customize this to your individual needs.
Unlike regular forms, there’s currently no session state concept for tabular forms, so you either need to write your data to the database, or you will loose any changes if you e.g. paginate. For the same reason, the “Add Row” button and the associated process is generated so that any changes are saved to the database before adding a new row. Of course the MRU process that is executed on “Add Row” can be removed, if that is the preferred behavior.
A work around would be to code the DML processes for tabular forms manually, and temporary store the data in HTML DB collections to simulate a stateful behavior.
In HTML DB 2.0 we started adding DHTML features, such as the create table wizard you’re referring to. Some features, like the pull down menus, will be available to be used in your own applications. Other features, like the DHTML tabular form, won’t be available for custom applications in 2.0.
Regards,
Marc