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

On Wednesday 01 November 2006 20:19, Pawel Piech wrote:

Hi Pawel,	

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

thanks for sharing your insights. Insteresting reading!

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

Even if the implementation is separated into distinct classes, it's the switch 
that is problematic, IMHO. It would still be the data model that would define 
in which views it would display (and you couldn't easily replace this).

That's why I proposed turning this relationship around and let the view (the 
presentation context) decide what elements to display. The advantage is that 
you can easily create an own presentation context to define what its 
associated view is able to display. Something as simple as 
view.getViewer().setPresentationContext(mySpecialContext) could do it.

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

Yes, I can certainly understand this. But I think that a little more 
flexibility/extensibility would be very helpful, especially if this framework 
is going to become part of the platform.

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

Sounds very interesting, but I can't comment on that right now -- I'm mostly 
focused on extending instead of implementing a debugger.

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


Back to the top