Components that search containers not handling repeaters

[jonathanaustin]

Components that need to search Containers do not always cater for WRepeaters and the row context logic.

These components, instead of just using the classic pattern for each child of the container need to use the doTraverse logic of TreeUtil that caters for WRepeaters and their row contexts.

Components affected are WFieldSet, WSelectToggle and Subordinate actions Enable/Disable, Mandatory/Optional.

Other classes affected UicStats, UicProfileButton.

Also check AbstractWComponent and collateVisible logic.

[jonathanaustin]

@ricksbrown @marksreeves question?

I have done a fix for WFieldSet that is set as Mandatory to handle a WRepeater with Inputs but had some questions about Subordinate and SelectToggle.

What behaviour would we expect for Subordinate actions of Enable/Disable and Mandatory/Optional to be on a SubordinateTarget that is a WTable or a WPanel holding a WTable, where the WTable has edittable columns. On the client side, would you walk through all the input components in the table and apply the subordinate action? If so, I will need to match this in the java.

Also....

What do we expect when a WSelectToggle targets a WTable and the WTable is Selectable. On the java side WSelectToggle currently handles WDataTable but does not handle WTable or a WRepeater with Selectable components. What does the client side do (or should do)? Again I will need to get the java to match the behaviour.

[ghost]

When a Subordinate action is not supported by the target the behaviour is defined by convention.

If the action is disable or enable then we follow the Java convention of testing descendants until we find a disableable component. We do not consider a table to be disableable and therefore this may vary if the affected component is WDataTable as we do not know if a table is a WTable or a WDataTable. If the table contains editable components then those components will be enabled/disabled.

For other actions the action is ineffective.

I will add some information regarding this to the wiki entry for WSubordinateControl.

[ghost]

With regard to WSelectToggle it looks like I may have broken it when we converted selected rows from role="checkbox" to role="row". I am not entirely convinced a WSelectToggle should toggle the state of rows but that is what it used to do so I will set about fixing it.

[ghost]

More info re WSelectToggle. It is a little bit broken. It will select rows in a WTable. It will try to select rows in a WTable even if the table is not multi-selectable. This will result in the last selectable row being selected. See #938