[Dev] automatically hooking into the sidebar

[John Anderson]

Hi Alec:

Whether or not you end up using bidirectional refs, I'd enjoy spending a 
few minutes tomorrow brainstorming about how they might be used  if 
you're interested.

John

John Anderson wrote:

> I don't think you should rule out using bidirectional refs because 
> everyone is busy -- although there may be other reasons to rule them 
> out. We use bidirectional refs in so many places that not being 
> familiar with them is a pretty serious handicap. There are lots of 
> examples in the code that uses them and I suspect none of us is really 
> too busy to answer a question about them now and then.
>
> John
>
> Alec Flett wrote:
>
>> John Anderson wrote:
>>
>>> 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 agree that a data-driven mechanism is the way to go - at least in 
>> the general case. Personally I think that the bi-directional 
>> reference with a container system seems like our best bet - my "Kind" 
>> mechanism is not ideal. (and I've done code-executing-at-startup and 
>> it ends up being pretty ugly)
>>
>>> 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.
>>>
>> That's not a problem I'm trying to solve for 0.5 anyway... so that's 
>> good.
>>
>>> 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.
>>>
>> I need it for ZaoBao as a proof-of-concept of extensions actually 
>> working in Chandler without being hard coded in. Given the realities 
>> of 0.5 (such as me not knowing enough about references in the 
>> repository or the parcel loader, and other folks being busy) I'd like 
>> to move forward with the "Kind" mechanism and discuss something 
>> better (i.e. the bidirectional reference mechanism) as well as the 
>> issue of user-intervention, for 0.6.
>>
>> 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