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

[Brian Johnson]

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

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)




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 :) *