[Dev] Generalizing Block.contents

[Donn Denman]

One of the great ideas in CPIA is the notion of block contents.  You 
determine what's displayed in a block by simply setting the "contents" 
attribute.  You want your block to display something else?  Just assign 
a new value to the contents attribute.  Easy!

Currently we use contents with Table and List blocks to display 
ItemCollections.  The Sidebar and Summary Views are good examples.  But 
some blocks, like the Detail View, are not designed to display multiple 
items.  Rather they tend to display a single item, or a single 
attribute of an item.  In these cases we're not yet using the 
"contents" attribute to determine which value should be displayed.  It 
would be nice to extend the notion of a block's contents to include 
these single Items and attributes too.

How should we do this?  There seem to be three natural choices for a 
more general notion of contents:
    1) Any Item can be used.  Since ItemCollections are themselves 
items, they are included too.
    2) An Item/Attribute combination.  This allows us to refer to a 
particular attribute as well as covering the above Item cases.
    3) Some more general notion of a data value, perhaps anything that 
the repository can hold in an attribute.

Whatever we choose to allow in contents, those values must support a 
small API: the block needs to be notified when the value changes, so 
the block can redisplay the new value.  We do this currently by 
subscribing to change notifications.  That's not so easy for case #3, 
where the value could be a string or other constant data.  Presumably 
we could use exception handling to "try" the API, and just leave the 
block's display constant if the value doesn't implement the API.

For the 0.5 release I hope to update the Detail View to use one of 
these schemes.  I like the simplicity of Option 1, and it seems natural 
that Items should be able to tell you when they change.  Option 2 looks 
good because this Item/Attribute descriptor is what's currently used to 
select an appropriate Attribute Editor for Attribute Editor blocks.  
Option 3 seems too general to be easily implemented.

Your comments are welcome.

- Donn Denman