Forum OpenACS Development: OK button and workflow actions in the form builder ...

I have a form that is in display mode and has some workflow action buttons (edit and comment, say) at the bottom.

When I click on one of the action buttons the "edit_fields" for that action are turned into edit mode. The transformation into edit mode takes place in an "if" clause in my form script that checks for the existence of an action. On the next page an OK (and Cancel) button appears ...

Now, when I click the OK button it, too, is interpreted as an action. But not the "ok" action as you might expect. Rather, the old workflow action (from the previous page) is brought along. The transformation of elements into edit mode will be carried out once again (in vain) AFAICS.

This becomes a problem if spell-checking is enabled and I have typed an error:

The spell-checker needs the relevant element to be in display mode in order to show the select boxes with suggested replacement words, etc, directly in the page. The spell-checker performs this transformation in case of an error but too early, it appears. Or rather, the change into display mode appears to get overwritten in the mentioned check in the form script ...

My basic questions are ... Is it necessery that OK is treated as an "action"? And, if so, is there a suitable check I might perform in order to tell the two cases apart - the case when I click an action button and the case when I click the OK button?

/Ola

Collapse
Posted by Lars Pind on
Yes.

The whole idea is that the form builder carries forward the action that was clicked originally for you. That's the only way we can know which action to execute in the end.

What do you need to know?

Do you need to distinguish OK and Cancel? If cancel is hit, you won't even reach the submit blocks of ad_form/form is_valid will not be true.

If you need to distinguish between the original action button click and the OK button click, again clicking an action will not set form is_valid.

/Lars

Collapse
Posted by Ola Hansson on
Right, I need to distinguish between the original action button click and the OK button click.

I tried the following - changes in bold - but it doesn't seem to work (this is actually from /lib/curriculum-ave.tcl):

...

# Set editable fields. Must do this after the "-form" block!
if { !$new_p && $wf_action_exists_p && ![form is_valid curriculum] } {

#    doc_return 200 text/plain "* [array get action] *"

    foreach field [workflow::action::get_element -action_id $action_id -element edit_fields] { 
	element set_properties curriculum $field -mode edit 
    }
}    

ad_form -extend -name curriculum -edit_request {

...
When I click the OK button is_valid is actually false ...

Thanks.

Collapse
Posted by Lars Pind on
is_valid has to be true at some point if you're submitting and there aren't any validation errors.

I'm not sure where ad_form actually creates the form, though.

Have you tried to move the code below ad_form?

/Lars

Collapse
Posted by Ola Hansson on
Lars,

I can't use "is_valid" as the check since it will return false even when I click OK, because in this case I'm having an inline spelling error. Instead, I can use "is_submission" as the check. It will return true when I click OK but not when an action button is clicked ...

Now I've detected a new problem, though. When the corrected text is submitted the element is updated with a null value (or "") ... Text that isn't spell-checked or that passes the spell-check without errors is updated correctly, however. In all other forms I've tested, this error is not seen.

Previously I've compared the spell-checking behavior in my script with that in bug.tcl, which (as opposed to mine) has worked fine. The only fundamental difference I spotted was that you're using the on_submit block in ad_form while I'm using the edit_request block ... I wonder if this comes into play here.

Now I find, however, that bug.tcl isn't working either - on the page where the spelling errors are shown the OK and Cancel buttons are missing. So I can't post the form and see if the corrected text is updated properly in bug-tracker.

I'll keep digging, but I'm beginning to go bonkers :-P

/Ola