This sounds like a really nice idea. The only negative thing that sticks out is this:
if the basic DML insert/update isn't good enough for you, change it to call stored procedures instead
Because that really breaks the API abstraction that permeates [Open]ACS 4, and doing that is risky (for instance, you might stick a mixed cased e-mail address in a party which breaks things - it's already broken in places and I'm busy fixing this so I thought it was a timely time to mention this particular example :)
But there's no good solution to get around this at the moment. Not all packages provide an "edit" API anyway and UPDATEs permeate the code, but the INSERTs really need to be avoided in general.
Maybe there could be a default "safe" mode that just screams "insert your NEW() and EDIT() calls here"?
Long term this and other things (Tom Jackson's "non-programming" tool) make me long for a higher-level description of the API that could be read and used to generate the proper calls ... another idea I've not thought much about.
Also ... is this written in a self-submission style using the form handler's validation code or ad_page_contract. OK, I'm being lazy by not looking but figured you probably know :) This is really how the form handler's meant to be used and it is nice when you do rather than validate via ad_page_contract, because the errors appear in the form with the offending values there for you to see.
Several of us have been talking elsewhere about better integration of the template and form builder systems with ad_page_contract and other ACS fundamentals but for now it ain't there, making things messier than they should be.
If people like Luke's package it would be great if someone would step up to look into doing an Oracle port. In general digging information out of Oracle's system tables is more straightforward than doing so with PG anyway.
