phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] Information sharing between modules


From: Dave Hall
Subject: Re: [Phpgroupware-developers] Information sharing between modules
Date: Fri, 16 Aug 2002 11:09:27 +1000

Hi,

This is a slightly editted and condenced version of the discussion
skeeter and i had on #phpgroupware, in response to his last post.  I
thought people might be interested in it and i hope it helps clarify to
things

skeeter My only comment there is that the plan is to only have the
app_id as the key to the apps table
skwashd the app_id i was referring to was the primary key of that app
table not the app_id of the actual application ... 
skwashd ie you have blah app with a table phpgw_blah and the values
stored are 123,'blah',321 ... being contact_id, app name and the value
from phpgw_blah.blah_id
skeeter I think maybe a 4 field link would make a little more sense...
skeeter app_id_1, app_rec_1, app_id_2, app_rec_2
skwashd the rec fields are the fk links ... right??
skeeter yes..
skeeter That way you can do something like: SELECT * FROM
phpgw_link_table WHERE app_id_1 = 1 OR app_id_2 = 1;
skwashd ok ... i would add a primary key of link_id to that so you know
the link you are deleting is the right one
skeeter ok..
skwashd wouldn't it be SELECT * FROM phpgw_link WHERE (app_id_1 = 1 AND
app_rec_1 = 123) OR (app_id_2=1 AND app_rec_2 = 123) ???
skeeter yes...
skeeter I didn't get as elaborate..
skwashd then there could even be a new link class which is able to
handle this stuff ... like so ...
skwashd find_links($rec,$app=$currentapp_id) and it does all the work
for finding the links
skwashd and delete_links($pk)
add_link($rec,$app=$currentapp_id,$fk,$link_app) and
check_links($rec,$app=$currentapp_id) ... the currentapp_id would be the
phpgwinfo array value
skwashd make sense??
skeeter Yes...
skwashd this way the apps would have to worry less about the linking ...
it could be handled centrally by the api for most stuff and enforce the
referential integrity
skeeter yeah..
skwashd there could even be a find broken links report in the admin area
... this way the broken links can be found and dealt with :)
skwashd it could even be run with a app or all apps filter
skwashd now i think i am getting carried away ;)

I think skeeter's suggestion to make it link to app-to-app not just
app-to-contacts will make the whole thing more flexible.  Currently I am
only using addressbook links but i can the potential in the future to
use this more widely.  I look forward to comments on this.

Cheers

skwashd
Dave Hall

"Mark A Peters (Skeeter)" <address@hidden> wrote:
> On Fri, 16 Aug 2002, Dave Hall wrote:
> 
> > Hi Chris and Brian,
> > 
> > Chris Weiss <address@hidden> wrote:
> > > I've done this to tts in a way that might work for everything. 
> I 
> > > added 2
> > > fields, reference_app and reference_id.  reference_app i fill 
> in 
> > > with my
> > > app's name, and reference_id with the record id in my app.  
> this 
> > > way I can do
> > > joins where reference_app = myapp and reference_id=myid for 
> > > displaying data
> > > from my app.  Would be trivial to have the other app check to 
> see 
> > > if these
> > > fields are populated before deleting.
> > 
> > This is good, but there is one problem ... it restricts you to a
> > One-to-One relationship between the contact and your app.  It 
> would be
> > better to have the possibility of many-to-many relationship 
> between the
> > contact data and the various apps.  For the stuff I am doing I am
> > planning to link to the addressbook quite extensively.  
> > 
> > I think this can be adapted to i have done mine as a link table 
> in my
> > app ... but it could become an addressboo> memory so please 
> imagine any mistakes are corrected :)
> > 
> > TABLE: addressbook_links
> > link_id - INT AUTO_INCREMENT PRIMARY KEY
> > contact_id - INT - FK phpgw_addressbook.addressbook_id
> > app_id - INT - FK appname.app_id (the primary key of the app record)
> > app_name - VARCHAR(50) - the name of the app it is linking to.
> > 
> 
> Be careful here.  Once I get back to coding in .15 and above, the 
> app_idwill be the only unique field between app_id and app_name.  
> I have
> remnants already built into .15 for allowing administrators to 
> update apps
> over the wire right from within phpGW.  This will allow the admin to
> upgrade apps against a master repository/mirror via XML-RPC.
> 
> eg.  Admin access update page in Admin module requesting a list of 
> new 
> apps or update from repository/mirror via XML-RPC.  Information 
> displayedback to Admin asking which apps to update.  List 
> submitted back to
> repository/mirror via XML-RPC and server sends back the 
> new/upgraded app
> in a XML-RPC package.  Admins server parses out and writes the 
> files to
> local server.  Then performs same update as in the setup/config/manage
> apps.
> 
> Back on the app_id, this will allow us to standardize on apps.  
> Developerswill then be allowed to register there app in the 
> repository/mirror and
> have the app U/L'ed and available back to the general public.
> 
> eg. Johnny Bravo develops a new app and registers it with the master
> repository.  The repository will assign his new app a unique app_id.
> 
> This way, you can have multiple apps named Calendar or Addressbook 
> and all
> handled by the app_id.
> 
> Thanks,
> Mark A Peters (Skeeter)
> 
> > I simple check could be added to the delete method so it call this
> > method, before deleting:
> > check_links($id)
> > {
> >   $GLOBALS['phpgw']->db->query("SELECT link_id FROM 
> addressbook_links> WHERE contact_id=$id);
> >   if(($GLOBALS['phpgw']->db->num_found())==0)
> >   {
> >     return true;
> >   }
> >   else
> >   {
> >     return false;
> >   }
> > }
> > 
> > Anyway, Just a thought
> > 
> > Cheers
> > 
> > skwashd
> > Dave Hall
> > 
> > > 
> > > Brian Johnson (address@hidden) wrote*:
> > > >
> > > >Is there an established method (even if just a concept) to 
> link 
> > > informationbetween
> > > >modules?  A standard method would be good since many modules 
> > > require contact
> > > >information and I couldn't find a current, practical way to 
> do this
> > > >
> > > >I don't mean I can't get info, I mean we need a method to 
> prevent 
> > > the other
> > > module
> > > >from deleting records that I'm linking to
> > > >
> > > >Currently my only solution seems to be to copy a module I 
> like 
> > > and add it as
> > > a
> > > >customized module to the module I'm working on.  It seems a 
> > > stupid way to do
> > > it when
> > > >the other module with the information is right there
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >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
> > > 
> > 
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> 

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]