[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-debug-dev] problems with the AsynchronousViewer framework


we're having a few problems with the AsynchronousViewer framework, compared to 
the "normal" JFace viewer framework. Please forgive us if we haven't 
completely understood the new framework. I'd also like to apologize for this 
long mail).

The JFace viewer framework is awesome, because it allows for reuse of so many 

1. You can reuse viewers and populate them with own elements by providing an 
own content-provider

2. You can adapt content providers (through subclassing), e.g. to add other 
elements, or to remove elements

3. You can reuse content providers to get a structural model without having to 
implement the logic how to get the elements or know how they are structured

4. Ultimately, you can display the same model elements in any number of views, 
by providing an own content provider or extending/reusing an existing one

------------------ (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"

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).

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, IPresentationContext context) 
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 

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().

Our specific problem was that we wanted to provide a new view for the JDT 
debugger, in order to display some I[Java]Variables that are special to us 
(using an IJavaBreakpointListener to get hold of them). However those 
variables never showed up in our view -- due to VariablesContentAdapter 
allowing variables to be shown solely in the expression, variables and 
registers views.

The only hac^Wsolution we found was providing wrapper-elements around some 
existing elements. I.e. we created a custom root element (instead of 
IStackFrame for example), for which we can define an own content adapter. 
That one returns wrapper objects for those special IJavaVariables. For these 
wrappers, we can again define an own content adapter, which "fixes" the 
VariablesContentAdapter by reimplementing supportsPartId() so that the 
variables also display in our view.

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?

I hope that it is not going to become a "best practice" to implement content 
adapters like the StackFrameContentAdapter.

Thanks and best wishes,
Fraunhofer Institute Computer Architecture and Software Technology, FIRST
Kekuléstraße 7, 12489 Berlin
Tel.: +49 (0)30 6392-1900, Fax: +49 (0)30 6392-1805

Attachment: smime.p7s
Description: S/MIME cryptographic signature