Conditional inquire: API etc suggestions.

Vladimir Voznesensky <[email protected]> Sun, 21 Sep 2003 22:08:51 +0400
Newsgroups gmane.comp.web.zope.formulator.devel
Message-ID <[email protected]>
Hi.
As mentioned above, I suggested to add conditions for fields to control 
suppressing of their rendering.
For example, when we fill up form for sick person, rendering for field 
"last gynecologist visit" can be suppressed for man.

1. 3 possible variants of how to organize getting fields satisfying 
their conditions:
a) get_fields_in_group, get_fields and get_field_ids return satisfying 
fields only;
b) get_fields_in_group, get_fields and get_field_ids have additional 
boolean parameter with default value, so when it has default value, then 
return satisfying fields only;
c) create new methods get_fields_in_group_conditional, 
get_fields_conditional and get_field_ids_conditional.
The main question is: how to make upgrade of existing scripts painless 
(i.e. without recoding)?
It seems to me, that script programmers usually use those methods for 
rendering and verifying field purposes rather than for editing forms 
themselves, so we can use b) and suppress non-satisfying fields by 
default without great disfunction. On the other hand, we need to check 
and hack formulator code carefully (especially, form editing methods).

2. has_field method makes more philosophy than get_... in paragraph 1.
Do script programmers use has_field at all? For purposes of 
rendering/verifying or for editing?
Suggestions?

3. Default render must render satisfying fields only. Does it need to 
render empty groups?

4. Shure, field TALES ZMI tab must have Inquire Condition field.

5. session_store & session_retrieve
Should they check conditions during store and retrieve?
Do we need it silently or raising exceptions?
I'm not familiar with sessions technique.

6. Validation.
Check up fields with satisfied conditions only.
If condition is not satisfied, REQUEST must not have appropriate key.

Regards.
VV