Is there any way to iterate throw recursive tree?

Hey all,

as far as I have understood the question, Victor wasn't looking for the selected node of a tree but wanted to reach all nodes of the recursive structure. Stefans answer has a static approach, which is not very useful if the depth of the tree isn't known or if it is large (where large means > 2 or 3).

So to reach all leafs for example (you could add the non-leaf nodes too), the following code could deliver a solution:

  ...
    ArrayList result = new ArrayList();
    getWholeTree(wdContext.nodeTree(), result);
  ...


  private void getWholeTree(IPrivateSomeView.ITreeNode node, ArrayList result){
      for (int i = 0; i < node.size(); i++){
          IPrivateSomeView.ITreeElement element = (IPrivateSomeView.ITreeElement) node.getElementAt(i);
          IPrivateSomeView.ITreeNode subNode = element.nodeChild();
          if (subNode.isEmpty()){
              // element is a leaf
              result.add(element);
          } else {
              // element is no leaf - add subtree
              getWholeTree(subNode, result);
          }
      }
  }

Maybe you don't like the recursive approach with a void method and the result as the parameter, but this is much faster for no objects (here: ArrayLists) have to be created within the recursion. For production code, for sure one would to have to assert "result" not being null, throwing an IllegalArgumentException otherwise and so on.

Hope it helps

Detlev

Hi Victor,

actually there is no implemented search method for the tree structure. If SAP in planning such a thing I cannot say.

Anyhow, I think the API's are under development, there will be many possible improvements, see for example problems-with-selection-in-table--context concering an iterator for selected rows of a table.

However, the recursive tree structure is much more complicated, because you are very free to define the recursion (node A has child node B has child node C has recursive child of type A, for example; or more complicated: node C has - beneath recursive child node of type A - an additional recursive child node of type B).

You also cannot build such a generic toolset by yourself, because at least, there is a generic method getChildNodes missing. All offered methods for child nodes are non-generic.

So at the moment you won't have another possibility than to build a specific method like the one offered above (for a standard case) - at least as far as I can realize this. Helmut, Karin, Stefan & Co, correct me if I'm wrong 😊

Hope it helps

Detlev

Hi Detlev and Victor,

well (sorry), it's not true, that there's no generic access to the child nodes or elements of a node, but most of these methods are not public. The generated context-specific methods are using those generic methods everywhere without you're noticing it. To be honest, since i've done manual programmatic access and manipulation of context structures (just because i was curious), i'm happy about this! Manual context programming is not really, what i want to do every day.

What we are really talking about here is what is exposed to be used by the WD application developer. This is always a "just as much as necessary, but without overloading the API" approach. Frameworks in general suffer from this, if they get too restrictive, they are easy to use, but not flexible, if they get too open, they will become error-prune and difficult to handle. This does not mean, that adding a method to get all child nodes or adding more collection-like methods would overload the context-API.

It would be nice to have generic collections available, but the fact is, that WD relieves me from those nasty things like taking care of type conversions for example by restricting me from using native Java types (in some cases) on the other hand. One can use the XMI model import to "convert" collections of value objects into the metadata form of WD (enabling the binding of view elements to those nodes/values).

Maybe it's possible to get the context handling a little bit more close to that of "normal" collections, but it might be difficult according to the automatic node- and attribute change tracking in the background.

Best regards

Stefan