Re: [dsdp-tm-dev] Should ISystemViewElementAdapter.showRefresh disableS

[Patrick Tassé <patrick.tasse@xxxxxxxxx>]

Hi,

Now that this is fixed (bug 285047), I'd like to explain why I had to disable refresh, and see if I could have done something differently.

I have a subsystem that supports filters. The filter applies to the boards of the target node. Expanding a board lists the program blocks, which contain running processes. The Remote Systems tree looks like this:

+ SubSystem
  + Filter
    + Board
      + ProgramBlock
        - Process

To get the list of processes, I only have access to a command that lists all processes on a board. The list results also give as an attribute the program block that each process belongs to.

So I handle the returned list and create my own ProgramBlock and Process resource objects. The ProgramBlock resource keeps a map of its child Process resources. When getChildren() is called on the ProgramBlock adapter, it can return the results without going to the target node.

Here is the refresh behavior that I would like to have: When I try to refresh either a ProgramBlock or a Process, I would like for the Board to be refreshed, to rebuild the tree under it.

But if I refresh a ProgramBlock resource, the code in SystemView$ResourceChangedJob(EVENT_REFRESH_REMOTE) will see that there are children and will just refresh the children (which in my case just returns the same processes from the ProgramBlock's internal map without going to the target).

When I refresh a Process resource, which is handled differently because hasChildren returns false, the behavior depends on whether there are matching filter references. If there are no matching filters, the refresh is delegated to the resource's parent, in my case a ProgramBlock resource which triggers an internal (and useless) refresh as described above.

If there are matching filters, then instead those filters are refreshed. The effect is that the board list is refreshed under the filter and the boards all become unexpanded -- see (*) below.

I guess what I'm looking for is a way for an adapter to delegate the refresh to its parent. Something like a canRefresh() method comes to mind. That way, the Process adapter delegates the refresh to its parent ProgramBlock adapter, which in turn delegates the refresh to its parent Board adapter, which this time performs a real refresh to the target node.

Does something like this exist already?

(*) There is another issue that I found while investigating this. In my subsystem the filter strings apply to the board name. But in the code above when the SystemView$ResourceChangedJob tries to find the filter references for, let's say, a process resource, it eventually finds my "All boards" filter for which the filter string is "*", even though the resource is not a board. This is because SubSystem.doesFilterMatch() automatically returns true for a filter string of "*", without querying my subsystem's doesFilterStringMatch() which could detect from the absolute name that the resource is not a board. This explains why the whole filter (which may or may not be the filter under which I am navigating...) gets refreshed instead of just refreshing the process's parent resource.

Thanks,
Patrick