[This message was posted by Steve Wilkinson of Cornerstone Technology Limited
<[email protected]> to the "Algorithmic Trading" discussion
forum at http://fixprotocol.org/discuss/31. You can reply to it on-line at
http://fixprotocol.org/discuss/read/68ba5a66 - PLEASE DO NOT REPLY BY MAIL.]
Looking at StateRules in some more detail, I find that there are some implied
constraints which aren't explicit in the spec. I would appreciate others'
views on whether my understanding is correct.
1. The spec says that StateRules that change the 'enabled' or 'visible' state
of a control have a direct mapping to the state of that StateRule (i.e., if
StateRule evaluates to true then enabled and/or visible = true and if StateRule
evaluates to false then enabled and/or visible = false). This implies to me
that there can only be one StateRule per control that manipulates 'enabled' and
one that manipulates 'visible' (although they could be the same one).
2. The spec says that except in the case where '{NULL}' is used, transition of
a StateRule (with a 'value' attribute) from false to true updates the value of
the control, but not in the reverse direction. This implies to me that there
could be more than one StateRule per control updating the 'value' attribute.
3. As a StateRule that uses the '{NULL}' value does affect a control's value
when transitioning from true to false as well as from false to true, this seems
similar to case 1, and would suggest that only one such StateRule should be
allowed per control.
So my questions are:
a) Are my assumptions about 'enabled' and 'visible' StateRules correct - only
one StateRule should be allow for each (per control)?
b) As there are obviously boundary cases about multiple 'value' StateRules
clashing on a given control, should we introduce a rule to also say that only
one 'value' StateRule is allowed per control?
My considerations are entirely theoretical - some real world examples of a need
to break these rules would help, assuming others disagree. However, I fear for
implementation complexity if we don't introduce such constraints.
Thanks in advance.
[You can unsubscribe from this discussion group by sending a message to
mailto:[email protected]]
--
You received this message because you are subscribed to the Google Groups
"Financial Information eXchange" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fix-protocol?hl=en.
