Re: [platform-debug-dev] problems with the AsynchronousViewer framework

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

Greetings,

Thanks for your input/use of the framework.

Since the asynchronous viewer support in 3.2 was provisional, you should 
stay tuned to the following bugs so you can see how the support is shaping 
up for API in 3.3:

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=153500
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=161435
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=154135

> 
> The JFace viewer framework is awesome, because it allows for reuse of so 
many 
> components:
> 
> 1. You can reuse viewers and populate them with own elements by 
providing an 
> own content-provider

Since the debug view contains mixed models (i.e. Java debugger, C debugger 
and others), one content provider is not sufficient. The platform does not 
know how to generate/update content for the models. Thus, the "adaptable" 
infrastructure allows for pluggable content and responding to model 
updates (via model proxy).

> 
> ------------------ (end JFace praise) ---------------------
> 
> It appears to me that some of the above advantages are lost with the 
> AsynchronousViewer framework (using the debug model as an example, but 
the 
> problems are more general, in our opinion):
> 
> 1. You can still reuse viewers and feed them with an own model "input"

(1) This seems more like a fact than "issue". I.e. - yes you can re-use 
views with your own input and content adapter.

> 
> 2. You cannot adapt a content adapter for an existing element because it 
is 
> fetched via IAdaptable.getAdapter(). You cannot provide an own 
> IAdapterFactory for an existing element (because you cannot "override" 
the 
> existing IAdapterFactory).

(2) This is true. The intended use case is for debug implementors to 
provide their relevant content adapters for their know use cases/views. We 
were not designing for others to extend/override content for a debug 
model. So, yes, this is currently a known limitation.

> 
> 3. You can still reuse content adapters (depending on their 
implementation). 
> Some debug model content adapters (e.g. StackFrameContentAdapter) 
however 
> contain hardcoded checks for the view in various methods. Example:
> 
>   protected Object[] getChildren(Object parent, 
IPresentationContextcontext) 
> throws CoreException {
>         String id = context.getPart().getSite().getId();
>         IStackFrame frame = (IStackFrame) parent;
>         if (id.equals(IDebugUIConstants.ID_VARIABLE_VIEW)) {
>             return frame.getVariables();
>         } else if (id.equals(IDebugUIConstants.ID_REGISTER_VIEW)) {
>             return frame.getRegisterGroups();
>         }
>         return EMPTY;
>    }
> 
> (Even worse in this example -- this content adapter provides a 
hardcoded, 
> different logic for all supported views, making it unusable for anything 

> else.)

(3) This is true. Since the same element has different content in 
different views, the adapter accounts for this. Returning "empty" content 
is probably a bad implementation for "unknown" views. The presentation 
context is used to tell the adapter what context content is being asked 
for. This is really the same problem as (2) - i.e. how to override or 
extend content provided by the "original" contributor (for new views).

> 
> 4. Elements can only be displayed in those views that the content 
adapter 
> supports, due to supportsContext()/supportsPartId(). Because an element 
is 
> basically tied to its content adapter, which cannot be replaced/extended 
(see 
> point 2), this means, that you cannot show an element in any other view 
than 
> those listed in supportsPartId().

(Yes , this is an elaboration on the same point).

> 
> For problem 2., it might be possible to reimplement 
> AsynchronousModel.getContentAdapter() and getLabelAdapter(). Would that 
be 
> the right way to provide an own AsynchronousModel (possibly inheriting 
from 
> an existing model) and reimplement those methods to provide own 
adapters?

In 3.3, we have a new implementation that does not use a model (cache of 
the model objects). In 3.3 (in a branch), we use a JFace tree viewer with 
the VIRTUAL support and a special content provider. However, the 
implementation is not intending to expose the viewer or content provider 
implementation. Only the content adapter interfaces will be exposed. So, 
in 3.3, this approach will not work.

I think that the issue boils down to one issue with the framework, which 
is how to extend or override content for existing models, when content 
adpaters are already provided. Right now the answer is that there is no 
way to do this. It is something we should consider.

Thanks,

Darin Wright