[formulator-dev] Conditional inquire: API etc suggestions.

[Vladimir Voznesensky]

Hello.

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 
get_field* functions.

>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
>speak up!
>
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 
condition failed.
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.

VV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infrae.com/pipermail/formulator-dev/attachments/20030930/594b1dd3/attachment.htm