Numeric_t.constValue and stateRule to clear fields

Imported from previous forum

[ original email was from Dev Ashish - dashish@lab49.com ]
2 questions:

  1. Numeric_t is the only parameter type which seems to be missing const and constValue attributes. Any particular reasons for this?

  2. What are the thoughts around how the UI is supposed to clear fields that may be used in stateRules and strategyEdit? For example, the sample OPLX strategy defines the following:

<flow:StateRule value="0">
<val:Edit field="Posting" operator="EQ" value="e_NOPOST"/>
</flow:StateRule>

<val:StrategyEdit errorMessage="DisplaySize does not match Posting selection">
<val:Edit logicOperator="OR">
<val:Edit logicOperator="AND">
<val:Edit field="Posting" operator="EQ" value="e_SMART"/>
<val:Edit field="DisplaySize" operator="NX"/>
</val:Edit>
<val:Edit logicOperator="AND">
<val:Edit field="Posting" operator="EQ" value="e_NOPOST"/>
<val:Edit field="DisplaySize" operator="EQ" value="0"/>
</val:Edit>
<val:Edit logicOperator="AND">
<val:Edit field="Posting" operator="EQ" value="e_Custom"/>
<val:Edit field="DisplaySize" operator="EX"/>
</val:Edit>
</val:Edit>
</val:StrategyEdit>

if the user selected e_NOPOST and then changed the value, the control with the stateRule will fail the validation since it didn’t get reset to NULL. In order to correctly handle this without writing special code, I had to add another stateRule (which looks hacky to me).

<flow:StateRule value="">
<val:Edit field="Posting" operator="NE" value="e_NOPOST"/>
</flow:StateRule>

For question 1: Numeric_t should be treated as a virtual parameter just like Parameter_t. Only types that correspond to valid FIX types (see tag 959) will have the attributes you listed.

For question 2:
This is a very interesting problem… A stateRule can change the value of three attributes: visible, enabled and value. Of these three, stateRule.value is the only one that is not binary. Ie. stateRule.value can be given any value. So when we wish to determine when a control should be visible or enabled (not greyed-out) it is easy to do so by defining just one stateRule. But to set the value of a control it may require a few more stateRules which, as you pointed out, seems to be a bit of a kluge.
I’m just stating this so that the terms have been defined. I think this needs some discussion followed by some direction by the WG.