Community
Participate
Working Groups
until now you can navigate to the selected node of a module group. with the attached patch it's possible to navigate to any node inside a group.
Created attachment 110362 [details] the patch file based on HEAD
In the patch the method navigate(..) in NavigationProcessor is changed so that it first uses the given target ID to find or create the root node of the target sub-tree e.g. a module group node. Then the same ID is used to find a child of that node e.g. a sub module. This appears strange: the module group and the sub module have the same nodeId? Also very unusual: NavigationNode gets a new method get*Child*(..) that may return the node *itself*. I think because of these issues the patch should not be applied as it is. There is another solution for the use case that the targetId refers to a tree (e.g. a module group) and that not the first sub module should be activated but a specified one: the NavigationArgument could be extended to hold an optional childId of a child to be activated.
accidentially closed...
Discussed this with Stefan: the idea is that the targetIdmay not be the nodeId of the module group created by the builder but the nodeId of the sub module to activate. The node builder decides (based on some application specific logic) that a module group (with another nodeId) must be created around the sub module. Then the node that must be activated is not the module group returned by the builder (what would cause the first sub module to be activated) but a child of the module group with the specified targetID. Since most of the time the node returned by the builder will have the specified targetId and would be returned by the getChild(..) method call on itself we agreed that the method should be renamed: findNode(..). We also agreed that the whole INavigationNodeId concept will have to be reviewed.
reviewed, discussed, fixed and applied patch
