Community
Participate
Working Groups
Build Identifier: I20100608-0911 Consider the scenario where XViewer contains the child items and the parent item does not match the filter criteria but child item matches. When filtering is done, since parent item does not match the filter criteria it will be removed from the view so child items are also removed even though filter criteria matches. Instead it should look for child items whether any of the child matches with the criteria. If so parent should not be removed so that child also visible. Reproducible: Always Steps to Reproduce: 1. Consider the data present in the attached screen shot. 2. Filter Child11, then it will not be visible in the table even though it matches the criteria.
Created attachment 201117 [details] XViewer Issue
I have tried implementing something like this in the past. Use case makes sense, but the devil is in the details. First problem: The way ViewerFilters work, the parents are given first and the filter is asked if it is visible. In order to make your case work, you would have to pre-process all children for all columns in order to determine if a parent should be shown. Secondly: You would need to keep track of those items that are expanded so that you don't expand additional items, but instead only match on those that are expanded. And Third: The XViewer, like all TreeViewers, don't required you to load all items first, but instead just the first level. Where it becomes expensive to load children, like in database provided data, you wouldn't want to search all children for matches just to figure out if parents match. All that said, I'm open to an elegant solution if you can provide one based on the current design. And based on the third issue above, we would have to make it toggle-able so the XViewer could be used for the load-all case and the lazy-loading case. Hope this makes sense.
Yes. You are absolutely correct. If it is implemented then it is against the lazy loading policy and it may hit performance also. Since my use case is a typical one, I suggest the following two approaches. 1. Just like RE option, one more option (preferably check box) can be provided to filter in child items. Once this is selected, table will be loaded fully and starts filtering in child items. 2. Otherwise provide option to customize existing filtering functionality for user needs. Right now all variables are private. It is better to make some of the variables (like xViewerFilter variable in CustomizeManager class and customizeMgr variable in XViewer class) protected so that user can customize the functionality as per his requiremnt.
You can already override the XViewer.getXViewerTextFilter() method to provide your own filtering. Will that support what you're trying to do?
Will the above fix work for your needs?
Yes. It works fine for my use case.
You can already override the XViewer.getXViewerTextFilter()
