I had a few people reach out and ask me about the Perspective tag browse tree I setup to recursively build with getConfiguration, and ask about a way to progressively build the tree as the user digs into it, to decrease loading time for large tag quantity systems. So I went ahead and built a version for that too!
I actually put this one on the exchange, but wanted to make sure it still works with @mraybourn’s Ad-hoc Trends page, so I made sure that this one is drop-in to that view and provides instructions for how to do so.
Its pretty thoroughly tested, but if you find any issues feel free to let me know here! As I am not sure its possible directly within the exchange yet?
Enjoy
Edit: If anyone is interested in the details of how it works, I can explain as well, just let me know and I will try to write it up as best as possible.
The progressive tag tree is really cool and very similar to something we built. Also suffered from slow loading when tag count got big.
One thing that I still want to build, but don’t know how, is a searchable tree view. It would be great to have a text field where you can enter a term and then filter the tags, say for anything matching %xyz%.
The problem is that you don’t know how deep in the tagpath the search term will appear. Do you need to browse recursively through the entire provider to match all the possible tags? How can you reject a chain early?
If anyone has an idea, I can try to build a solution
You could use getConfiguration with recursion to get everything in one shot and then search through it with the keyword provided by the text field. Then just dig through each directory and return anything that matches? May not be the most optimal but at first thought I would think it’s the easiest way to do it
Love it. I added a function to sort the tags alphabetically as well. Use this function wherever you return the tags list in the items binding, and the event script.
def sort(tlist):
names = []
for l in tlist:
names.append([ l['label'], l])
ds = system.dataset.toDataSet(['name','tags'],names)
ds = system.dataset.sort(ds,0)
tlist = []
for d in system.dataset.toPyDataSet(ds):
tlist.append(d[1])
return tlist
User type some part of tag path and tag tree filtering base of that and expand tree for user.
I mange to do it with system.tag.browse(path,filter) with filter option but it cause each time the tree close and user have to go all the way down.
I am pretty close to finished with it, but I have a few questions about expected behavior:
Should it only filter the currently open folders since this is the progressive loading tree? Or do you expect it to act more like the tree using getConfiguration that loads everything at once?
Should it ignore folder labels and only pay attention to tag labels? Then if it ends up with a folder that has nothing in it, should it just hide that folder?
Should it update on each keypress?
Should it be case sensitive?
Let me know any other clarifications you think would be good, I have it all working without re-collapsing the tree at each filter. I just need to fix an issue for when you clear the filter to allow it to “un-filter” the tree. I will finish it tomorrow
I believe loads everything at once if user select the root. and only filter folders when select a folder.
It is better to pay attention to full path which include both path and tag name and tag atomic member. If folder has nothing it should show to user to inform him.
Yes.
Is it possible to expand the tree to see the end result of filter? for example we have PT1 in Cellar folder, when user type PT1 tree expand Cellar folder to show it to user.
But the only thing matter most is fast response.
Ideally the filter should apply to any tag anywhere in the structure. E.g. I’m looking for a valve XV123, but it could be multiple folders deep and I don’t know where it is it yet. The problem would be that the search must consider the entire structure, but then filter the results to only include the path crumbs that lead to an eventual hit. Loading all the nodes collapsed just kills clients when you exceed a few thousand.
I think it should consider folders, as you may be searching for a UDT instance name, which would appear as a folder.
The delay as Nader suggested is a good idea. How would you handle the first few keypresses? Searching for ‘a’ might produce a load of results.
I don’t think it should be case sensitive, as this would make it a bit more cumbersome to use, especially on touch devices.
This sounds like a job for my tag tree that collects everything with ‘system.tag.getConfiguration()’ instead of recursive browsing
So after typing a filter, it should expand any folder necessary to show all tags/folders that match the filter?
I think I can do this efficiently without harming the client, by either using ‘getConfiguration’ instead of ‘browse’, or storing the data in an intermediary dataset not applied to the ‘self.props.items’ so that it can progressively load through that dataset
Ultimately the way I implemented the search doesn’t really care if you return every row or one row
You both disagreed, so I’m sure this will become an in-script toggle
Ultimately though something came up in my plate today, so it will probably be a tomorrow item. We’ll see if I need a break from my actual work hahaha
Yes it is better expand any folder necessary to show all tags/folders that match the filter.
But in the end do what is simple and easier for you and also preserve performance.
You can always make it better in future.
Creating the list of all the filtered tag indices within the tree = Easy
Expanding the list automatically = Easy to do, but very slow…
I have it currently working in a format that expands all of the tags that match your search and highlights them. It works ok with my example (about 1000 tags) but still isnt as fast as I would like.
Top items to correct:
It needs to also remove/hide the tags and paths that don’t match the filter.
In my example each of my UDTs has Level and Gallons, if I search something like just “Gallons” that matches~500 of the tags, it takes closer to 10 seconds. Unacceptable
I moved the search onto a button, the recommended way of delaying the search from the typing doesn’t work in perspective due to the way invoking threads asynchronously works with your session. I will have to create a new way of doing this as well.
I had to remove the alphabetical sorting due to the way the item paths are generated, I will have to fix this as well.
Anyways, here is a gif!
Also here is the current version in case anyone has any ideas on how to improve what I have so far. Definitely a fun little project TagTree.zip (16.5 KB)
I use 8.0.12 and it doesn’t work for me. As you see in below image in folder DPH I have a lot of tags and folder not it didn’t show up in result when there is no filter. every folder show system and default tag.
Community collaboration is everything ignition is and others aren’t. I ran into this issue a while and did it differently but it’s nice to see the community work to make it better. (Will take down later due to relevance)
hahaha
