Re: [Phpgroupware-developers] addressbook model and integration with accounts

[Dave Hall]

Brian Johnson <address@hidden> wrote:

> Dave Hall (address@hidden) wrote:
> >
> >Brian Johnson <address@hidden> wrote:
> >
> >>
> >> don't forget to show the relationships to phpgw_links as used by
> >> infolog/inc/class.solink.inc.php
> >
> >I think Ralf is working on a API proposal for this.  If this happens
> >then it should be included.  If not then it is outside of the API 
> and so
> >I don't think should be shown in this model.  For example many 
> apps use
> >the current contacts data, these are not shown in the model.
> >
> 
> Many apps use the current contact data?  I think many apps DON'T 
> use the current
> contacts data 

off the top of my head, addressbook, email, infolog, projects, phonelog,
timetrack, tts

> because the contacts data does not check to see if 
> anything links to
> it before deleting a record.
> 

This should be handled by a more generic data_link class.

> Splitting the people and orgs is only one half of the goal of this 
> revision.Providing a method for other apps to link to contacts 
> data without fear of some user
> deleting it is the second half of the (or at least my) goal.  
> Without both halfs,
> why bother doing the first half?

I think it should be wider than just contacts data.

> >>
> >> could someone explain to me the comm system again?  I still don't
> >> understand why we
> >> need three tables there.  Shouldn't two tables be sufficient?
> >>
> >
> >Ok, here goes.
> >
> >phpgw_contacts_comm
> >holds the actual communication data:
> >phone#,
> >fax#,
> >mobile#,
> >email address,
> >url/uri,
> >pager#,
> >IM info,
> >etc etc
> >includes some future proofing
> >For each comm_type_descr_id a preferred could be set where there are
> >multiple entries - such home email or whatever
> >
> >phpgw_contacts_comm_descr
> >holds the actual descriptions of that communication type:
> >Work Phone
> >Home Phone
> >Mobile/Cell Phone
> >Fax
> >Work Email
> >Home Email
> >Pager
> >Jabber
> >AIM
> >Website
> >etc
> >
> >phpgw_contacts_comm_type
> >holds the information about each type of communication technology
> >initially I see these including:
> >Landline Phone
> >Mobile Phone (because of sms)
> >Fax
> >Email
> >URI
> >IM
> >
> >The class field is for some new contacts_comm_* classes.  These 
> classes>would hold several methods:
> >validate($val) - used for validating the input
> >can_send() - returns bool
> >return_uri($comm_type_id) - for making links from data ie mailto: or
> >linking to phpgw apps/tools for handling these types.
> >send($comm_type_id, $msg)
> >
> >Note different phone types would extend a base phone class.
> >
> >These classes would be configured in an admin option - communication.
> >Setting basic info about the servers - ie email servers, sms gateway,
> >fax, jabber info and if someone develops something to allow php 
> to talk
> >to Bayonne (http://www.gnu.org/software/bayonne/index.html) we 
> can use
> >that too.  There would also be user prefs to support these 
> changes too.
> > This data could then be used by the alarm management tool in 
> calendar>or the brute force protection notification.
> >
> >The active flag is so a system admin can allow or disallow these
> >communication types from being entered.
> >
> >I hope I have explained this clearly.  This is concept which is still
> >buzzing around my head.  I hope to have something on the 
> communication>concept on the wiki in the next week.  This is part 
> of my holiday coding
> >activity.
> >
> 
> I suspect this will need to be simplified prior to it's 
> implementation (likely get
> rid of the phpgw_contacts_comm_type table).  It seems like extra 
> complication that
> is unneccesary since it seems like the function associated with 
> these items could be
> directly associated with the types in phpgw_contacts_comm_descr

No this is poor 3NF design.  comm_type has a 1:n relationship with the
comm_descr table.  I know this may appear complex atm, but I think leave
it a week and you will see the reasoning behind it.  The main reason for
the extra table is for the comm_type to provide enhanced communication
from with in phpgw.  The class field stores the extended name of the
contacts_comm_* class for handling that communication type.  

Under your proposal you would duplicate the handler class name 5 times
in the case of IM (Jabber, AIM, Yahoo, M$N and ICQ) twice in the case of
pager/mobile (cell) phone (the xml (not xmlrpc or soap) sms gateway i am
evaluating supports pagers too).  A sysadmin could just select the type
from a select/option list.  This also allows the easier addition of new
handler classes - I think of a new one each day :)

This also allows sysadmin some flexibility over the communication types
they allow users to have access to.  

One thing to remember with all of this, the smarts are in the contacts
classes, so any dev can use it, without knowing the intracies of it.  A
data model that may appear complex does not need to be complex when
calling the classes that sit on top of it.  

Cheers

Dave

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>