I think I've isolated one of my confusions with ad_form. Ad_form has more actual modes than are documented or named directly controllable, or even described in Ola's last message. It has:
- displaying form for new entry. Proposed name: new form
- Handling new mode POST. new post
- Displaying new mode post with errors (ew form w/errors
- displaying Edit form for existing entry existing form. May or may not have errors, same mode either way. previously called 'edit'
- displaying read-only for existing entry existing display, previously called 'display'
- handling edit mode POST existing post
Did I miss anything? Can we hammer out the actual rules it uses to figure out which mode its in? Then we can make this modes explicit, first in docs, then in standard usage and example code, and then maybe in ad_form itself. A first stab at the rules is
- Was an element_id passed in? (I think this implies that the form defines a 'key' field).
- No element_id passed in: we are in New Form.
- Yes, element_id passed in. Does the key match a record already in the system (can be tested by ad_form_new_p, but ad_form uses different code to actually determine this?)
- No, key is not preexisting: We are in New Post and expecting a submission. Are there any errors?
- no validation errors: redirect to the default in aftersubmit (?)
- yes, validation errors: we are in New Form w/errors. Display errors in something that looks like mode 1 but now has an id set.
- Yes, key already in use: What is the -mode flag for ad_form? (It can be controlled from the url if you code a custom variable to hold it and then pass it in to ad_form, but there is no standard way to do iths)
- -mode is Display: we are in Existing Display
- -mode is Edit or not set: we are in Existing Edit or Existing Post.
Now can we map this back to the ad_form flags, and maybe straighten out the terminology?
