|
I try to do a summary here, numbers as above:
1) TREE filtering instead of search/filter is not ideal (my bad in my first post) since user (and/or developer) would get into trouble by editing the filtered view, so no editing but endless forth and back between filtered view and complete view, and the complete view is the whole, expanded tree, so navigation problems in order to do the wanted edits: user's work would be possible but very cumbersome.
2) Thus, I suggest to add the necessary code to SEARCH. Can be done by an intermediate sql "view" with (virtual = just here, not stored) numeric path column by numeric path representation, then sorting by that (1.1.4.1 after 1.1.4 and before 1.1.5, currently it would come after 1.1.5 which breaks the tree preservation).
3) I present 3 ways of doing TREE filtering (see 1), a, b, c:
c being a flat list (possible if you really don't want to do the SEARCH thing (see 2),
b would be too demanding code-wise since for also graphically maintaining the tree, you would need to also show all "hidden" items (in light grey) but which would be necessary for the graphical tree representation of the non-hidden items
a (which you currently chose) is unacceptable since some non-hidden items ARE hidden though, since they are children / grandchildren / etc of hidden items (which are left out), so if you don't want to do c = flat list but graphical tree representation, you can't left out non-hidden items but must also preserve "hidden" items to "hold", to "situate" the non-hidden items = solution b = lots of code
To make this as clear as it gets: Currently, you do a = seemingly preserve the tree but hide "non-hidden" items which "depend" from hidden items, so it currently does NOT make sense, example:
hide everything except red and green
a is red, child b is green, you correctly show both
but a has another child, c, which is black, and which has a green child d on its turn;
you hide the non-to-be-hidden item d since you hide its black parent c
Hence the (complicated) solution b, or the (simple) solution c, here in TREE solution.
4) BUT as said, solution c in the tree (= flat list) would correspond to the SEARCH solution (from which you refrain because of the necessary, demanding coding), AND I say, since it's the similar code anyway, in the SEARCH results solution AND in the TREE solution, please do it (= the flat list, preserving the tree structure) per SEARCH results, since then
- the user can work concurrently on BOTH panes: for their deciding what to edit / move / etc they would consult the search results, and for their edits / moves / etc they would have the tree available in the state they need it to be for these edits, moves, etc
- the user can use ANY search for this work (e.g. searches for keywords, tags, whatever) for this editing-and-shuffling work, whilst if you do the flat list within the tree pane, this would only apply to flags, so the "usefulness scope" of filtering-while-preserving-the-tree-structure would be greatly enhanced, compared to the flat-list Data Explorer solution (with no extra developing work compared to the latter).
As said, "TREE a", your current "solution", is not a solution, since it hides items which are NOT to be hidden, just because they have the "wrong" parentage (which in a flat list would be easily hidden indeed).
So, "TREE b" (= also show the necessary "in-between" items) is complicated and not worthwhile, "TREE c" (=flat list in Data Explorer) would be possible but not easier to code than the flat-list "SEARCH" solution, and quite awful for the user, hence my suggestion to implement a SEARCH OPTION "preserve structure" (or "preserve hierarchy") (in the flat list, not also graphically of course), as another checkbox in the pack "Search titles only", "Match whole words", etc., and which would OVERRIDE any current column sort settings.
(I also said the additional code, with the creation of the intermediate SQL "view" from which then the "hierarchy sort" is done, should, of course, only triggered whenever the option "preserve structure" has been set for the search / filtering.)
This would then be available for ANY search / filter, not only for flags.
I hate to say it, but the developers of RightNote and MyInfo both implement quite nice features on a quite regular basis (especially MyInfo, whilst RightNote lately added the option to have TWO, concurrent Data Explorers, for alternative views, and which ironically, if we had them in UR, would invalidate my reservations re the TREE solutions (Tree b and Tree c, whilst current Tree a cannot be), whilst on some core functionality NOT being in the class of UR, so it's not a bad idea to ENHANCE and develop the STRONG points in UR's interface and functionality, unparalleled over there, and structure preservation, even as a default, might be considered a core functionality anyway - by which I don't wanna say that alternatively, all the numerous, but all structure NON preserving columns sorts weren't needed.
Again, "do it right" instead, in the Data Explorer, would be possible, but not less work than to put hierarchy preservation as an option into the search... which would be so much more useful for the user: much better workflow than Data Explorer toggle, and availability for ALL searches / filterings.
|