[Dev] Generalizing Block.contents
twl at osafoundation.org
Thu Oct 21 17:16:00 PDT 2004
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.
More information about the Dev