This class is designed to be used in place of the standard ISMP feature selection panel. It provides a more attractive appearance and adds the capability of providing descriptions along with the feature names. Dependency and parent/child relationships among the features can be defined, and indentation of individual features can be controlled.
The features to be shown on this panel are defined via an ordered list of beanIDs, which must correspond to features defined within the project's product tree. If the list contains an invalid beanID, it will compile OK but at runtime the panel will contain error messages.
The names and descriptions shown for each feature are drawn from the "displayName" and "description" properties of the associated feature bean in the product tree.
The entries in the list should be annotated to define initial
state and formatting options. Features followed by a "+" sign
will be selected on initial display and those followed by a "-"
will appear as unselected. The ">" symbol preceding a feature
indicates that the name and description for that feature should
be indented in the display. Multiple ">" symbols will cause
further indetation. Here's an example:
feature1+ feature2- >feature3+ >>feature4+ >>feature5- >feature6- feature7+
It is furthermore possible to define dependency relationships among the features in the list so that, for example, selecting incompatible feature sets is prevented. Specifically, three types of relationships can be defined:
feature1+[&feature2][!feature3] feature2+[&feature1][!feature3] feature3-[!feature1][!feature2] feature4-[!feature7] >feature5-[*feature4][!feature7] >feature6-[*feature4][!feature7] feature7-[!feature4][!feature5][!feature6]In this example, features 1 and 2 have an inclusive relationship, and they each have an exclusive relationship with feature 3. Feature 4 is marked as the parent for features 5 and 6, and all three of these features have an exclusive relationship with feature 7.
Notice that inclusive and exclusive relationships are logically commutative, so the dependencies should be defined in both directions in the list. That is to say, if A "ands" B, then B should "and" A as well.
A word of caution: It would be quite easy to define rules in this
list that do not fit together. Don't do this! There is
no error checking in the code for this, so the results are
unpredicatble if you define, for example:
feature1+[&feature2][!feature2]That's a pretty obvious error, of course, but other more subtle ones are certainly possible. So be careful in what you define.