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

[Ralf Becker]

The only docu I have made so far about the links are inline docs in the 
source-files infolog/inc/{so|bo}link.inc.php.

The so-class implementes the links as n to n links in the db-table 
phpgw_links. The bo-class adds an application registry, where each 
application can register functions for searching and viewing entries 
(via a hook) and the facility to attach files.

You can view it with our (buggy) inlinedocparser:
http://www.phpgroupware.org/cvsdemo/doc/inlinedocparser.php?app=infolog

or view the relevant sourcefiles on savannah:
http://savannah.gnu.org/cgi-bin/viewcvs/phpgroupware/infolog/inc/class.solink.inc.php?rev=1.12&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup
http://savannah.gnu.org/cgi-bin/viewcvs/phpgroupware/infolog/inc/class.bolink.inc.php?rev=1.15&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup

I will put a proposal about the link-class into the wiki in the next days.

Ralf

Dave Hall wrote:
> 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
> >
> >
> > _______________________________________________
> > Phpgroupware-developers mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers

--
----------------------------------------------------------------------
Ralf Becker
digital ROCK, Becker & Macht GbR            Telefon +49 (631) 31657-51
Leibnizstraße 17                            Telefax +49 (631) 31657-52
D-67663 Kaiserslautern                 EMail address@hidden