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