[This message was posted by Scott Atwell of American Century Investments
<[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/776e1c2e - 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.
I believe that there should only be a single StateRule controlling 'visible'
and 'enabled' (and it could be the same one), otherwise you have the potential
to have conflicting rules 'fighting'. Those are boolean rules and evaluating
the rule can clearly determine the 'rule evaluated to false' thus 'set the
control to the opposite state'.
The 'value' StateRule is different as it can represent multiple values. Take a
TextField as a simple illustration. It can have an unlimited set of values.
I've seen a real world case where there are radio button controls (or a drop
down) representing aggressiveness (think Low, Med, High) and a TextField for
Percent Of Volume with StateRules of if RadioButtonLow then value="5", if
RadioButtonMed then value="15", if RadioButtonHigh then value="25". In this
case there would be multiple StateRules with 'value='.
The 'value' StateRule with ="{NULL}" is a more special case. It drives whether
or not the control should be considered to "have a value". And this, in turn,
drives whether or not the parameter associated with the control has a value and
would be populated within the FIX message. Some controls such as Clock may
always 'appear' on the screen with some value, however, if value="{NULL}" is
set then it won't be eligible to go on the wire (in this case it's also a good
idea to set enabled="false" to help the user 'know' this).
Thus, no I do not think you can restrict a Control to only one 'value'
StateRule.
[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.
