Re: Conditional inquire: API etc suggestions.

Hi there,

Thanks for this useful analysis of the situation. I'll add in a few
responses below:

Vladimir Voznesensky wrote:
> 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).

I agree that choice b seems to be the best. And yes, it does need
careful modification of all Formulator internal code so we do get
all the fields whenever we need to.

> 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?

I don't know. :) I would imagine has_field we could give the optional
argument as well, and return 'false' if to the view of the programmer
the field is not existent.

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

Good point. I guess empty groups should not be rendered.
 
> 4. Shure, field TALES ZMI tab must have Inquire Condition field.

We can have a checkbox field in the Edit tab and then you can override
this using TALES. The checkbox field in itself is useful for people
playing around with enabling/disabling fields. Perhaps we should
call it 'disabled' though it would be odd that a field gets included
on the disabled = false condition then. We could also have
a checkbox field called 'enabled', and it's also turned on by default.

> 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.

Hm, I don't use these methods a lot myself. People who do, please
speak up!

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

Should there be an explicit check that if the field is disabled, the
REQUEST shouldn't have the key, or is it enough to simply ignore
any such key?

Thanks again for the analysis!

Regards,

Martijn