Hi Alec:

This is just one of many situations where we need to have a mechanism to "register" something declared in a parcel with the system in a way so that it gets discovered.

As it turns out there are lots of ways to do this. The "kind query" scheme you're proposing is just one way we've discussed doing it. Another interesting possibility we've discussed is using bidirectional references on ref collections, e.g. assigning an attribute hooks the a corresponding reference on the other end of a system collection that can be used to find the registered things. Another possibility we've discusses is executing code at parcel load time -- which seems not quite as nice as the two previous data driven schemes. Finally, none of these deal with the possibility of allowing the user to participate in choosing between registered alternatives, e.g. choosing between alternative viewers for a particular datatype.

I think in the case of the sidebar, however, it would be nice to register a new item collection as well as an optional viewer (today we only have two, table and calendar). However, all this is beyond the scope of 0.5.

This is clearly an area that needs to be fleshed out post 0.5, with input from UI, design and by considering our other registration needs, so I think it's premature to add it as described without further discussion.

John

Alec Flett wrote:

So I've been working on a system for chandler extensions to "plug in" to the sidebar and I'm curious what people think of my scheme. Here's how it works:

   * I added a new Kind, <SidebarCollection> that derives directly from
     <ItemCollection>
   * I added a rule to the <ItemCollection
     itsName="sidebarItemCollection"> - see below....

<contentModel:ItemCollection itsName="sidebarItemCollection">
<_inclusions itemref="content:allItemCollection"/>
<_inclusions itemref="content:inItemCollection"/>
<_inclusions itemref="content:outItemCollection"/>
<_inclusions itemref="content:CalendarView"/>
/ *<!-- this allows extensions to hook into the sidebar -->
<_rule value="for i inevery '//parcels/osaf/framework/blocks/SidebarCollection' where True"/>*
/ </contentModel:ItemCollection>


   * For ZaoBao, what I was able to do was make its type derive from
     <SidebarCollection> as follows:

 <Kind itsName="RSSChannel">
   <superKinds itemref="content:ContentItem"/>
/*    <superKinds itemref="docSchema:SidebarCollection"/>*/
  ...

Now, every time ZaoBao makes an RSSChannel, that object is also a SidebarCollection. the RSS Channel need only populate itself as though it were an ItemCollection, and its items will appear in the summary view.

Now I don't know enough about queries to know if this is really a smart way of searching the repository for items that want to hook into the UI... is there a better way than creating a new Kind?

Alec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Reply via email to