Re: [Phpgroupware-developers] Information sharing between modules

[Mark A Peters (Skeeter)]

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 addressbook/api table.  This is all from
> 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_id
will 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 displayed
back 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.  Developers
will 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
> > 
>