Skip to main content

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

Hi All,
I'd like to chime in on this discussion as well, since I've been doing a lot of development in this area lately.  I'm writing a framework for debugger implementations that partially side-steps the standard debug model and populates the debug views using its own set of adapters.  See http://dsdp.eclipse.org/help/latest/index.jsp?topic=/org.eclipse.dd.dsf.doc/docs/dsf_white_paper.html for more info on the framework.

My comments:

A.) The adapter association with elements is required to allow the view content to be populated from multiple different sources.  This is requirement for the debugger mainly on the account of the Debug view.

B.) The adapter mechanism is wonderfully simple and powerful, but it is limited in that no additional parameters can be supplied to the getAdapter() call.  This means that the IPresentationContext parameter has to be given to the adapter itself, which results in the rather ugly pattern of :
if (contextId.equals(IDebugUIConstants.ID_VARIABLE_VIEW)) {
	return something;
}
else if (...) {
	return somethingElse;
}
But there is no reason why this logic couldn't be confined to a single class which does nothing but handle this switch and delegates to adaptors that service a specific view. 
For the standard debug model, Darin didn't choose to use this pattern and I can understand why.  Most of the debug model elements have an identical or very similar presentation in different views, so there is no real need to make a big differentiation for different views in the design.  But this is just a characteristic of the standard debug model adapters and not of asynchronous viewer in general.

C.) I believe that to fully take advantage of the asynchronous viewer capabilities, it is important to provide yet another level of abstraction in the adapter layer.  This layer needs to have its own model - view model, which is fully decoupled from the data model, and this is the design that I'm using in DSF.  However DSF defines both the data model paradigm as well the view model.  It also has a bunch of other design restrictions, so I'm not sure if it would be practical to use its design with the standard debug model.

Cheers
Pawel

Carsten Pfeiffer wrote:
On Tuesday 31 October 2006 18:16, Darin Wright wrote:

Hi Darin,

thanks for the quick answer!

  
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:
    
Thanks, I will.

  
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).
    
Right. Interestingly, the EMF has chosen a similar approach (using adapters 
for every element type to provide children and labels).

  
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.
    
Yes, exactly. Sorry for my poor wording. I wanted to point out that two out of 
those 4 items are still OK.

  
(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).
    
As in point (1), this wasn't meant as an issue, but as something that is still 
OK compared to JFace. That is, in general it's still possible to reuse 
content adapters; only the specific implementations of some debug model 
content adapters are problematic.

I'm wondering if it would make sense to move the definition of which elements 
to show from the content adapters to the presentation context.

I.e.  instead of checking whether the context belongs to the variables view

if (contextId.equals(IDebugUIConstants.ID_VARIABLE_VIEW)) {
	return something;
}
else if (...) {
	return somethingElse;
}

ask the context if it supports variables:

if (context.supports(IDebugUIConstants.VARIABLES)) {
	return something;
}
else if (...) {
	return somethingElse;
}

(The latter somethings and somethingElse might actually not be exclusive if a 
view would support variables *and* registers for example, so maybe a list 
containing both should be returned.)

That would make it possible to
- extend existing views with new content (by setting a new presentation 
context, possibly inheriting from or delegating to an existing one)
- create new views and reuse existing adapters by using an existing 
presentation context

Additionally, the presentation context could be the entity to ask for content 
adapters. That way, a custom context could either return the default adapter 
from the IAdapterFactory or another one.

Thanks,
Carsten
  

_______________________________________________ platform-debug-dev mailing list platform-debug-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/platform-debug-dev


Back to the top