[Dev] Generalizing Block.contents

[Donn Denman]

On Oct 21, 2004, at 5:16 PM, Ted Leung wrote:

>
> 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?
It's not clear to me if queries provide the notifications in the more 
general case - though some part of the repository would need to be 
involved.
>
>>
>> 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.
Good, we'll talk about this in more detail when you're in the office in 
November.

- Donn
>
> Ted
>