somewhere, somehow, we need some recursive summary information.
in ghini.desktop we have it in the status line, and it is relative to the search.
here with this recursive taxonomy structure, you see a taxon, you read how many direct verifications it has, but you don't know how many it is if you consider all its subtaxa. it is an expensive computation, and we don't want to start the computation unless explicitly requested. the computation must run on the server, and the client must wait for the result, and must be able to inform the server of the computations it isn't interested in any more.
one option could be to start it when the user clicks on thebutton, but consider that hitting the button makes it disappear, so when you again select the same row, we need to save the summary information somewhere. even worse, who knows maybe the computation hadn't finished yet, and the mechanism receiving the information from the server should stay active even if the user selects a different row in the meanwhile.
somewhere, somehow, we need some recursive summary information. in ghini.desktop we have it in the status line, and it is relative to the search.
here with this recursive taxonomy structure, you see a taxon, you read how many direct verifications it has, but you don't know how many it is if you consider all its subtaxa. it is an expensive computation, and we don't want to start the computation unless explicitly requested. the computation must run on the server, and the client must wait for the result, and must be able to inform the server of the computations it isn't interested in any more.
one option could be to start it when the user clicks on thebutton, but consider that hitting the button makes it disappear, so when you again select the same row, we need to save the summary information somewhere. even worse, who knows maybe the computation hadn't finished yet, and the mechanism receiving the information from the server should stay active even if the user selects a different row in the meanwhile.