Image a password input entry in a dialog. Say, the user-entered password
should obey some rules, each rule corresponds to an invariant cell. We
If violate invariant cell A, then prompt user "A rule violation"(e.g.
"password too short").
len_ok <= check_len(password)
contains_valid_character <= check_character(password)
Current "invariant cell" may not play well in this case, since:
- If password cell is poison, we can't say whether it's too short, or
contains invalid character, or some other reasons.
- Adam needs calculate all cells in output_index and then say the
password field is invalid, compare to the normal "event handler" way -- the
later will detect an invalid user-entered password quickly.
Shall we need associate a "reason" with an invariant cell? If violate
cell, the "reason" will be returned to the client.
Shall we track which invariant cells mark a cell poison?
Shall we try to check the inputs in the beginning of update phrase? Is there