Community
Participate
Working Groups
Nested filters have never fully worked in RSE, and the concept is questionable. Anything pertaining to nested filters should therefore be removed from RSE API, in order to avoid confusion, e.g. class SubSystemConfiguration: public boolean supportsNestedFilters() class SubSystem: protected Object[] internalResolveFilterString(IProgressMonitor monitor, Object parent, String filterString)
[Kushal Munir wrote] Regarding nested filters, I know that we had planned on providing support for these at one point, but it was deemed too complicated for the customer to use and was never fully implemented (in universal or iSeries). It also wasn't clear what a nested filter would look like and how to best present it to the user (e.g. would we show them as filters within filters? Would the resolved children of a filter and its relative filters be shown directly under the filter in the tree view? That might be somewhat confusing.) We didn't really have satisfactory answers to these usability concerns and we didn't have any customers asking for such a feature in the first place. A top level filter can be used to do the same thing that a nested filter can do. I think the framework currently allows an extender to implement nested filters, but I'm not too sure to what extent it provides support for it. I think it only provides persistance within the framework, everything else is left to the extender, but I'm not too sure. I wouldn't recommend using it and I think we should remove it from the framework altogether, since we don't know the impact of having it. In my opinion, nested filters provide little value in the framework. Even without RSE providing support for nested filters explicitly, I don't think there's anything stopping an extender from implementing such a thing themselves. The only thing they have to figure out really is how to persist the nested filters, which presumably should be possible using the new persistence provider. I would rather keep things simple in RSE.
I'm revising this... maybe we'll want nested filters after all. This needs to be discussed in the context of a larger plan item on filtering. Deferring to "---" for now.
