Don mailed me that he doesn't like the key-guessing code in
ad_form_new_p. He's right, it's an ugly kludge (it loops through all
available variables, and if there is only one with a name ending in
"_id" then it assumes that one is the key). The problem is that with
the current separation of ad_form and ad_page_contract I don't see an
easy solution for a better key guessing in ad_form_new_p.
Here's what happens currently when using ad_form for new and edit requests in one file:
A new request is usually at first a GET without the key
defined. E.g. linked to from from another page, like this:
<href="note-add-edit">new note</a>.
When entering some values in the new form, and doing a submit that
does not validate, e.g. because a non-optional field was left empty,
then the new form will be redisplayed with an error message next to
the offending fields. This redisplay will be a POST request, with the
key variable set to a pregenerated value, __key_signature will be set
to a non-empty value (not really sure about that), and __new_p will be
set to 1.
An edit request will initially be a GET with the key variable set.
Upon redisplay because of a validation error it will be a POST with
the key variable set as well, and __new_p set to 0 (don't know about
__key_signature here either).
I don't see an easy way to find out if it's a new form without explicitely knowing the name of the key variable, so I will just make -key a required parameter for ad_form_new_p for now.
