Re: [platform-debug-dev] Memory View Infrastructure Review: Part 1

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

This response just deals with the issue of binding a rending to a type of 
memory block.

> 
> =======================================
> <Samantha>
> I agree with you that having the class name in the extension is fragile
> and that changing the classname breaks the extension point.
> 
> The reason why the classname is used is that I wanted to allow someone 
to
> define a rendering for a particular class. For example, someone might 
come
> in and want to develop a rendering for all types of memory blocks. If we
> take
> the approach of matching it with a string from getMemoryBlockType, then
> we will have to bind all the known memory block types to this new memory
> rendering type.  If we are matching it to a classname, then we can 
simply
> bind the new rendering with IMemoryBlock.  All memory blocks can now 
take
> advantage of this new rendering type.
> 
> I know having a rendering type bound to IMemoryBlock is an extreme case.
> However
> if a debug adapter has multiple types of memory block, then this
> may be useful for contributing a basic rendering type to a base memory
> block type.  And have
> more advanced rendering types only contributed to some of the memory
> blocks.  We cannot
> do this type of rendering definition by simply matching it with a string
> from
> calling IExtendedMemoryBlock.getMemoryBlockType().
> 
> Would returning an array of strings from
> IExtendedMemoryBlock.getMemoryBlockTypes() a good
> alternative? Implementers of IExtendedMemoryBlcok should always call
> getMemoryBlockTypes() from its super
> class to obtain a list of memory block types. We can have renderings
> contributed to specific type of renderings and
> have hierarchy taken into account while making it more flexible. 
(Changing
> the classname
> won't break the extension.)
> 
> =======================================
> 

The requirement for binding a type of memory block to a rendering is that 
it needs to be flexible enough to allow a rendering to be bound to 
all/many memory blocks (for general renderings, such as the HEX 
rendering), or to specific types of memory blocks (for specific 
renderings, such as a GIF image or an HTML rendering of text). Thus, I 
propose that we use the very flexible expression enablement language to 
bind a rendering to a memory block. The expression language is used in 
many extension points, such as contextual launch, and allows for an 
extensible set of properties to be used to determine when a contribution 
(rendering, in our case) should be enabled (bound). The expression 
language already supports an "instanceof" test that we can re-use to 
support the current "memoryBlockClass" condition.

Thus, a <renderingBinding> element would have an <enablement> element in 
place of the <memoryBlockClass> attribute. The enablement expression would 
be evaluated with an instance of a memory block, as the "selected 
element".

A similar approach could be used for <defaultRenderings>. An enablement 
expression can enable a list of default renderings for a memory block.

A plug-in that contributes a rendering should describe the requirements 
for a memory block to be considered. For example, if I contribute a GIF 
rendering, I should document that the GIF rendering considers all memory 
blocks that provide an "IGIF" adapter (or whatever condition I choose). 
This allows upstream plug-ins to re-use the rendering.

Darin