com.katharsys.pub.cx
Class RequireText

java.lang.Object
  extended bycom.katharsys.pub.cx.RequireText

public class RequireText
extends java.lang.Object

The RequireText CX allows the user to create a relationship between a TextFeature and another model node to determine when the TextFeature is required. If a TextFeature is always required, the simple checkbox "Input Required" should be used instead of this CX. However, when TextFeatures are required based on other selections in the model, this CX provides that conditional behavior.

Rule Definition
Model Node Select the node that determines when the TextFeature is required
Java Class com.katharsys.pub.cx.RequireText
Java Class Instantiation With Model Node Instance

Author:
Ken Truesdale, Katharsys LLC

Constructor Summary
RequireText()
           
 
Method Summary
 void requireText(oracle.apps.cz.cio.IRuntimeNode condNode, oracle.apps.cz.cio.IRuntimeNode textNode)
          Defines the TextFeature's conditional requirement.
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Constructor Detail

RequireText

public RequireText()
Method Detail

requireText

public void requireText(oracle.apps.cz.cio.IRuntimeNode condNode,
                        oracle.apps.cz.cio.IRuntimeNode textNode)

Defines the TextFeature's conditional requirement. The first parameter is the conditional node, and therefore the BaseNode of the rule. The second parameter is the TextFeature to be required when the condition node is true.

Conditional nodes can be any of a number of different types of model nodes. If the conditional node is a BooleanFeature, an OptionFeature, an Option, a BOM Instance, a BOM Option Class, or a BOM Standard Item, the condition is true when the conditional node is true. The same is true for a CountFeature (an IntegerFeature with a min value of 0 or higher). For IntegerFeatures (with a negative min value or no min value at all), Decimal Features, Totals, and Resources, the condition is true when the value is greater than zero. You can even use a TextFeature as a condition where the condition is true if the TextFeature has a value entered; when true, it causes the second TextFeature to be required.

You can use Components as the conditional notes, but there are a few things to keep in mind: if the Component is a BOM Component, the condition would be based on the description above for those nodes; if the Component is a simple Configurator-created Component, it will always be true (there are no states with Components); and, most importantly, if it is a Component in a ComponentSet (where it can be created or deleted by a Component control), the Component will be true when it is created and then the condition will never go away, even if the component is deleted, since the absence of a node can't fire the CX to be not true. Therefore, under most circumstances, you will not want to use this CX with Configurator Components. If you needed to track the count of a Component instance, you would want to create a Total that tracked the instance count and have the instance contribute 1 to the Total; then that Total would be the condition to use in this CX.

This CX is designed to represent one condition per CX Rule. If you have multiple cases of conditionally required TextFeatures, you should create a CX Rule for each case. Be careful to not create conflicting relationships with this CX where one CX Rule tries to require a TextFeature at the same time a second CX Rule tries to make it not required. If you find that you have many of these conditions, your needs may exceed this rule and instead create a custom CX that aggregates all of the required conditions into one CX Rule.

With most conditions, you will probably want to create two bindings. You should have a binding for a PostValueChange on the condition node as well as a binding with PostCXInit to capture the scenario when the model loads with the condition node in a true state. (Perhaps from a model restore, for example.)

The binding to the first node is left open to be any IRuntimeNode for purposes of allowing the BaseNodeOfRule to work. If a node other than a TextFeature is used as the first parameter, the CX will be ignored.

Event Binding
Event postValueChange and/or PostCXInit
Scope Base Node
Method requireText
Argument Binding(s)
Arg 1 Argument Type IRuntimeNode
Argument Name condNode
Argument Specification System Parameter
Binding <BaseNodeOfRule>
Arg 2 Argument Type IRuntimeNode
Argument Name textNode
Argument Specification Model Node
Binding the TextFeature that should be required when the condition, determined by the conditional node (Arg 1), is true



Copyright © 2010 Katharsys LLC. All Rights Reserved. Implementation-Version: 0.1-b46