I have a SQL table and used to populate a tree view in vision (for sake of this question I entered bogus data):
Query:
SELECT a.id, `number` AS `text`, `number` AS `selectedText`, `name` AS `path` FROM tdssql.joblist a
INNER JOIN jobcustomer b ON a.custid = b.id
WHERE `name` LIKE '%{Root Container.txtlistJobsFilter.text}%' or
`number` LIKE '%{Root Container.txtlistJobsFilter.text}%'
SQL table:
In vision it was simple, but for the life of me I can’t seem to grasp the concept in Perspective. I’m assuming I will need a transform? Can anyone help me on this?
Yep, I’m actually using a named query in Vision, I just copied the query to show what I was doing. The same query doesn’t work across vision tree view and perspective tree view. All I will get is the labels or main folders. I’m guessing a transform is needed just not sure how to go about it.
Edit: This is what happens using the same query as in Vision:
Each object in the props.items array is formatted in a specific way to display the structure you are looking for.
For instance each item consists of
{
"label": "My Item",
"expanded": False,
"data": "1" #This can be anything, a string, list, dictionary, you name it,
"items": []
}
Then if the item is a folder, it would contain more of that same structure inside the items array in that dictionary.
I went ahead and threw together a script that converts your query in a script transform, but you may need to play with it to get exactly what you’re looking for. This is with the named query output set to JSON in the binding
customers = []
items = []
for job in value:
if job['custid'] not in customers:
item = {
"label": "Company #%s" % job['custid'],
"expanded": True,
"data": "",
"items": [
{
"label": job['number'],
"expanded": False,
"data": {
"jobID": job['id'],
"description": job['description']
},
"items": []
}
]
}
customers.append(job['custid'])
items.append(item)
else:
for index, customer in enumerate(customers):
if customer == job['custid']:
itemIndex = index
item = {
"label": job['number'],
"expanded": False,
"data": {
"jobID": job['id'],
"description": job['description']
},
"items": []
}
items[itemIndex]['items'].append(item)
return items
Well, I spoke too soon. While it works, it is insanely slow. If I click on an item, it takes 2-5 seconds to react. I can tell something is going on since my laptop fan is on full afterburner. On a perspective table you can limit how many items are visible at a time, I guess there isn’t anything like that on the tree?
This isn’t related to this binding, this would be an issue afterwards potentially due to the size of the data represented.
How many rows is your table starting out with? You may be loading in a really large amount of data that the tree just can’t render very well. There may be ways that it can be optimized depending on if that’s the cause or not
I think the speed issue you’re seeing is actually with the designer trying to render the item property array with a 4000 row object. Unfortunately the designer is not a fan of large properties, try putting it into a page and opening it in a client and see if that resolved the issue
On the vision tree view, if you type a letter the tree view will select a row with a name beginning with that letter. Is this functionality not supported in Perspective?
Definitely follow up here with the outcome if you can, I am curious whats causing it, and it may help others to know too.
This is actually something that isn't natively supported at this time due to the way that the tree is built. However it is something that I have started to pursue at the request of @nader.chinichian in this thread (Perspective Progressive Tag Tree - #19 by miyanalu) but Its still a work in progress.
I called IA and we discussed the tree component in Perspective. He had a good point on how to test, we bound to a query and used the transform. The speed was slow. We then unbound and the speed was the same. So, to us the speed issue wasn’t related to the query or transform, but just the amount of data. I could have typed the items in by hand and it would still behave the same.
I still think there is an issue, but at least I know it’s not the script or query.
Did you ever try changing the access settings on the props.items for the tree?
I don’t remember exactly what to set it to, but I know @PGriffith mentioned in another post (that I can’t find) that changing the access setting here can really help. Something about how the page loads the properties? He can probably clarify better
Since you’re using it for the tree itself, changing property visibility to private isn’t an option; if private, it would never reach the front-end to be used for the tree’s actual rendering.
Is there any special format you could use a dataset like in vision? Its unfortunate often times when the weight of the json structure being rendered in the designer makes large things like this often impossible. Datasets typically tend to let things load quite a bit faster
For what it’s worth, changes landed in today’s nightly (should make it into 8.1.1) that should dramatically improve performance in the designer when interacting with large, complex JSON structures.
