Re: RE: RE: [Phpgroupware-developers] Re: phpGroupware database and u ml d ocumentation in wiki?

[Dave Hall]

Brian Johnson <address@hidden> wrote:

> Here's my real issue:
> 
> If I want to make an app that has records that link to addressbook 
> records, I want
> to make sure that addressbook checks for the possible existence of 
> my links prior to
> allowing a record to be deleted since that would totaly screw up 
> the integrity of my
> data.  THIS IS A CRITICAL POINT.
> 
> But, I don't think it's practical to have addressbook have a 
> special check for my
> links to it's records, and I know that other apps could bnefit by 
> sharing the
> contact records in addressbook (through links) and I don't think 
> it's pracitcal to
> have addressbook check for every possible link from a list of 
> other apps

Hooks :)

> 
> Extraploate that to apply to apps other than addressbook (calendar 
> is another one
> that immediately springs to mind) and you can see the benefits of 
> a standard linking
> system for each app to take advantage of.
> 
> I'm not sure what you mean by hard-wired system, I don't think the 
> linking system
> behind infolog is one. At it's core it is one table that includes 
> five fields (id,
> app_id1, record_id_app1, app_id2, record_id_app2)
> 

That is my original idea, and I am glad to ralf has implemented it :)

> 
> 
> 
> Michael Dean (address@hidden) wrote:
> >
> >On Sat, 2003-06-14 at 00:12, Brian Johnson wrote:
> >> I don't think I'm going out on a limb to say that most of us 
> consider addressbook
> >> and calendar to be part of the core system that other apps 
> would/should tie into
> better.
> >
> >They certainly are core apps, but are not part of the API.  
> Although, I
> >do consider the functions they provide (along with communication) 
> to be
> >core components of a groupware system.
> >
> >> As for duplicated tables with the same info, I know for certain 
> that timetrack
> >> duplicates parts of addressbook, accounts, and hr because those 
> apps don't provide
> >> what timetrack needs in their current form.
> >
> >My point to Kai was to demonstrate not every module creates 
> copies of
> >tables from other apps if it needed that information.  It seemed 
> to be
> >what he implied as he wants a huge static schema instead of a modular
> >one.
> >
> >> A standard inter-app linking system is needed.  The linking 
> system included with
> >> infolog (please relaize that I'm talking about the code behind 
> infolog and not just
> >> the ui .. although that is good too for viewing and creating 
> links) is the most
> >> flexible and easiest to standardize system.  It basically boils 
> down to one table.
> >> It should be used.
> >
> >I don't think you really want a hard-wired standard system here.  At
> >least not at the physical database structure.  You can easily create
> >classes to abstract this functionality, but depending on the 
> situation,>it is not always a good idea to link everything in one 
> table among the
> >various apps.  This is where you would get app specific - 
> especially for
> >performance reasons.
> >
> >Mike
> >
> >
> >
> >_______________________________________________
> >Phpgroupware-developers mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> >
> 
> --
> Brian Johnson
> * This is where my witty signature line would be if I bothered to 
> edit this line :) *
> 
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>

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