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

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.

Fraunhofer Institute for Computer Architecture and Software Technology, FIRST
Kekulestraße 7, 12489 Berlin

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