[Chandler-dev] Contacts/Address Book project

[Bryan Stearns]

Ernesto,

It sounds like you're asking for arbitrary sets of repeating blocks (for 
instance, a value editor and a label editor for each of several email 
addresses) - the detail view currently only supports fixed sets of 
blocks for a particular Kind, though blocks can be shown/hidden based on 
the item being viewed. Until this can be changed, I'd suggest starting 
with a detail view that can display one email address and one phone 
number; once that's working, I can help you expand it into a 
conditionally-visible fixed number of fields.

Can you describe what you're going for? Maybe I can also suggest what 
blocks and what attribute editors need to be built, and what can reuse 
existing stuff...

...Bryan

Ernesto Rivera wrote:
> (http://wiki.osafoundation.org/bin/edit/Journal/AddressBookProject)
>
> The project's plan has changed -upon several requests- giving highest 
> priority to the "conforming to vCard" task, which will be continued by 
> the import/export to vCard task.
>
> The main problem for the coming days will be creating "dynamic" detail 
> views allowing (like OSX's Address Book):
>
> - Visually creating an arbitrary number of entry fields (3 email 
> fields, 4 phone numbers, etc.).
> - Visually tagging each of this fields (home, work, etc.).
>
> Is out there something like this anywhere on Chandler? I guess I will 
> have to create my own specialized "blocks". In this case where to start?
>
> Now some answers to past emails (all this topics are also on the wiki 
> page):
>
>
> Ted,
>
>>
>> I think that you should spend some time thinking about how contacts  
>>
>> are linked to other items.   We are going to have tasks which are  
>>
>> assigned to people (or waiting for someone to complete something  
>>
>> else), events which involve people, and so forth.   One way of  
>>
>> looking at people/contacts is that they are a hub for organizing  
>>
>> information.   I may have a meeting scheduled with Katie and want to  
>>
>> know which tasks I am waiting for her to complete so that I can  
>>
>> continue.    I might want to know all the meetings that I have with  
>>
>> Bobby in the next week.   I think that the interesting use cases  
>>
>> around Contacts revolve much more around data which is linked to  
>>
>> contacts, as opposed to stamping items as contacts.
>>
>
> I was thinking about a "see everything related to this contact" popup 
> report.
> Most items already create a bidirectional link to the contacts 
> involved (event participants, item creator, group membership, etc.)
>
>>
>> In the section "Implement the role of groups" you say "propagate  
>>
>> actions to group members".   Which actions are you talking about here?
>>
>
> For instance sending an email to a group of contacts should be 
> "propagated" sending the email to each individual group member as it 
> is not possible to send the email directly to the group.
> I see propagate as a "do this action for each member on the group".
>
> Other actions don't need such propagation: if you add "Chandler_devs" 
> group to your office hour event, the event should keep track only of 
> the group and not their members as they may change.
>
>> While I agree that it should be possible (actually, it should be  
>>
>> trivial) to have contact items show up in the All collection, I'm not  
>>
>> sure that there is much utility in this.   The All collection might  
>>
>> have quite a bit of stuff in it, which will probably make it hard if  
>>
>> you are just trying to find the contact for a particular person.     
>>
>> Also, once we get the dashboard view in place, contacts aren't going  
>>
>> to fit in well with that usage of the summary view area.     It  
>>
>> should be very easy to create an address book collection which  
>>
>> contains all contacts, and this would certainly be a way to get  
>>
>> something up and running quickly.   But I think that we are  
>>
>> ultimately going to want to have an optional pane which can appear in  
>>
>> any application area.   I would encourage you to talk some more about  
>>
>> the design with Mimi.   For Chandler 1.0 we are trying to support a  
>>
>> specific set of workflows and functionality, and we want the contacts  
>>
>> functionality to mesh well with what we are already planning to do.
>>
>
> I will detail this point on the project's page.
>
>
>
> Mike,
>
>> Another thing I thought of as I was reading your tasks on the wiki page
>> was this: Couldn't Contact Groups be handled by using the existing
>> Chandler concept of a Collection?  I'm not sure if this has been
>> thought of and rejected but my thought was that any Contact could be
>> added to any number of collections and that would allow you to
>> manipulate the Contact's membership separately from the actual Contact
>> data item.
>
> Currently a ContactPerson and ContactGroup are subclasses of Contact 
> abstract superclass, so you can use as you like single persons or 
> groups anywhere.
> To make groups also a collection would require it to be also a 
> subclass of pim.CollectionItem, which shouldn't be an issue on Python 
> right? While allowing drag and drop functionality.
>
> However:
> a) Adding them to the sidebar (or worse requiring groups to live 
> there) doesn't look practical.
> b) Allow adding non-contact items to the group collection? yes/no? 
> why? Any collection should become a group collection if at least a 
> contact item is contained?
>
>>
>> I would also urge that you keep an eye out for the fact that almost
>> every item you have in a "normal" Contact schema will have multiple
>> occurances.  Note I said "will" and not "could" - someone somewhere
>> will want 20 phone # while another person will want 20 addresses and
>> yet another will want 3 different name fields.  Not that you need to
>> support that now, just keep it in mind
>
> Yes, this will be part of the "conforming to vCard" task. However 
> certain fields (as the name field) should only contain one entry to 
> avoid vCard conflicts.
>
> Creating the schema for this should be quite easy. The difficulties 
> will come when implementing details view's "dynamic" behavior (like 
> OSX address book's view).
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060703/72e1533b/attachment.htm