[Dev] Generalizing Block.contents

[Ted Leung]

On Oct 21, 2004, at 11:26 AM, Donn Denman wrote:

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

Are you expecting to get a notification via queries as well?  Or do the 
change notifications get triggered by a query?

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

+1 for option 2.

Ted