Forum OpenACS Development: Re: ad_form for new and edit requests

Collapse
15: Re: ad_form for new and edit requests (response to 1)
Posted by Ola Hansson on 02/07/04 05:45 PM
Hey Joel,

This is a little confusing at times, I know ... You could think about it in the following way: The form builder (and consequently ad_form) has two modes; "edit" and "display". The script has two modes or blocks; "new" and ... well "not new". The "new" block always renders the form in edit mode but the "not new" block renders the form in either edit or display mode.

What the code does first is it determines if a new element should be added or if one already exists (the if/else clause above ad_form). What decides this is whether the element_id query var is provided or not in the request. If the script enters the "new" mode - remember that this is not a form builder mode - the form will go into edit mode. This is the default and would've been used even if I hadn't explicitly told ad_form to use the edit mode.

Now, if in the page request you provide an element_id, and the page is not in "new" mode but in the other mode which I haven't named yet 😊, the form will go into either edit mode or display mode depending on what you tell ad_form. If you don't tell ad_form anything it will default to edit mode (and an editable form will be rendered). But since there is a -mode switch to ad_form you may instruct the form to enter display mode if you so desire (and the form will be rendered read-only).

When the form is rendered in display mode (read-only) an "Edit" button appears below the displayed data (unless the -has_edit switch is being used) and, if pressed, the behavior of form builder is to _force_ itself into edit mode so that you may edit your data.

In case you want to provide a way to choose whether to render the form (for an existing element) read-only or not (the two links example you gave) you can do so by accepting a separate (optional) query var which you could call "mode" or "read_only_p" (say), and let the presence (or absence) of that var have an influence on the $form_mode var in the "not new" block of the script.

(In the element-ave.tcl script I apparently defined the "mode" var for a similar purpose, but as far as I can see it's never used anywhere in my script ...)

Does this make it clearer or dimmer? 😉

/Ola

Collapse
16: Re: ad_form for new and edit requests (response to 15)
Posted by Joel Aufrecht on 02/09/04 11:10 AM
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:
  1. displaying form for new entry. Proposed name: new form
  2. Handling new mode POST. new post
  3. Displaying new mode post with errors (ew form w/errors
  4. displaying Edit form for existing entry existing form. May or may not have errors, same mode either way. previously called 'edit'
  5. displaying read-only for existing entry existing display, previously called 'display'
  6. 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).
    1. No element_id passed in: we are in New Form.
    2. 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?)
      1. No, key is not preexisting: We are in New Post and expecting a submission. Are there any errors?
        1. no validation errors: redirect to the default in aftersubmit (?)
        2. 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.
      2. 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)
        1. -mode is Display: we are in Existing Display
        2. -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?