[formulator-dev] Conditional inquire: API etc suggestions.
vovic at smtp.ru
Tue Sep 30 21:23:32 CEST 2003
Thank you for your answer.
Silence pushes me into pessimism :) .
Martijn Faassen wrote:
>Thanks for this useful analysis of the situation.
Well, thank you for your formulator and for your attention to the
feature that I need :) .
>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.
However, we must guarantee, that if a programmer have not touched
anything related to conditional inquire, his system would show the same
behaviour as it were before the upgrade.
Ok, let's has_field will have the same conditional semantics, as
>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.
Agreed. Moreover, it is the standard way: we have Edit field and we can
override it's content.
>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.
A psychological rationale:
Logical true is associated with 1 rather than 0.
1 (in a 0 background) is associated with "exist", "appears", etc.
We formulate condition of APPEARANCE.
So, the field should be called "enabled" and be 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
Well, it seems that usually programmers validate values before storing
them into the session.
As well, programmers are responsible for content of their session objects.
>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?
There are at least two possible cases when the REQUEST have a key whose
First, the state of the system can mutate between form rendering and
results validation, so condition that have been true became false.
In any case, programmer MUST consider such case, so we should warn a
programmer about it, is not it?
Second, rogue hacker can add a key&value that must not appear in some
specific dictionary assembled from REQUEST.form .
It seems to me that programmer could expect that after validation
REQUEST.form would consist of enabled fields only.
On the other hand, normally programmer use get_fields() to manipulate
the values, so in this case he will not get wrong keys&values.
Nethertheless, you have much experience than my humble person ;) .
We should consider a typical use case here.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the formulator-dev