organizing the tree (dataexplorer), filtering...

[pawe]

There are a many threads on how to organize / filter overloaded trees in big databases. I just want to add one very static / rudimentary solution, which would solve about 90% of my personal tree-related annoyances:

A (static) template attribute (checkbox): "do not show in tree"

These items consequently would behave like files in the windows explorer:
- they show up only in the child items window (not in the tree)
- they are a dead end for the tree (as files are compared to folders in the windows explorer) - well, not necessarily, see my following post below.

Especially in databases with a relatively small tree structure but with tons of sibling document items, the browsability of the tree would become strikingly better.

I wonder if there are other users with the same problem?

[pawe]

An additional thought to my post above:

These "items hidden to the tree" have not necessarily to be a dead end for the tree:

If the active item and its parents ALWAYS show up in the tree (regardless if they are "hidden" or not), then also children of "hidden items" become selectable in the tree.
The hidden item itself can only be selected in the child items window. But then it shows up in the tree, and its children get selectable in the tree.

This requests a dynamic updating of the tree with every selected-item-change in the child item window.

[wordmuse]

I *LOVE* the overall idea!

I'm kind of confused about the refinement. If an item is hidden, how does it show up in the tree?

Yes - almost anything to help me diminish visual clutter is a good thing. :)

Great idea.

Regards,
Bal

[pawe]

Originally posted by wordmuse

I'm kind of confused about the refinement. If an item is hidden, how does it show up in the tree?


The only goal of the idea to "make hidden items visible" is that they still can have accessible child items. If this sounds too geeky to a developer reading this, please let me add the most important for me would be to have them, regardless of if they can have child items or not.

- As said above, the "Hidden Item" would only be hidden in the tree (dataexplorer window), but not in the Child Items Window. So the hidden item itself can only be accessed via the child items window.
- Double-Clicking an item in the Child Items Window normally makes it the active item in the tree: for a "hidden item", this would make it visible in the tree.
- In consequence, child items of a selected (i.e.visible) "hidden item" should also become browsable in the tree.
- The same should apply for "hidden items", which are in the lineage (parent) of the selected item in the tree: it has to be visible in the tree.

The implementation of this requests a dynamic updating of the tree, as "hidden items" are changing their visibility depending on them being in the lineage of the active item.

Example:

Full Tree with hidden items:
Tree
|-Item1
|-Item2
| |-HiddenItem2a
| |-HiddenItem2b
| | |-Item2b1
| | |-Item2b2
| |-HiddenItem2c
|-Item3
| |-Item3a

Now what is visible depending on the active selected item:
Tree
|-Item1
|-Item2 <--selected (no hidden item selected - none of them visible)
|-Item3
| |-Item3a

Tree
|-Item1
|-Item2
| |-HiddenItem2a <--selected (via the child item window)
|-Item3
| |-Item3a

Tree
|-Item1
|-Item2
| +-HiddenItem2b <--selected (expandable, as it has children)
|-Item3
| |-Item3a

Tree
|-Item1
|-Item2
| |-HiddenItem2b (is visible as a child is the selected item)
| | |-Item2b1 <--selected
| | |-Item2b2
|-Item3
| |-Item3a

[wordmuse]

Ahh - now I understand.

Let me offer an alternative to this idea that would, I think (... I *think*) would suit me better.

If you double clicked a hidden item in the child window, it opens in a new tab as a hoisted item with that item as the hoist-root in the Explorer pane.

Thanks a lot for the explanation.

Regards,
Bal