[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[platform-debug-dev] problems with the AsynchronousViewer framework
|
Hi,
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
components:
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
else.)
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,
Carsten
--
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