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