Re: [Phpgroupware-developers] Information sharing between modules

[Dave Hall]

Hi Brian,

Brian Johnson <address@hidden> wrote:
> NOW THAT'S THE GLOBAL SYSTEM I WAS LOOKING FOR - yes I'm excited

I thought it was a bit of inspired thinking from skeeter.

> 
> Nice and simply too, a four field table

I would use something like link_id as a 5th field and have it as the
primary key ... to ensure deletes and updates are working on the right row.

> 
> It's still up to each module creator to use it, but at least the 
> concept is standardized

Do you plan on developing the classes for this?  If so what are your
time lines?  I am interested in contriubting ... but not for a couple of
weeks.

Cheers

skwashd
Dave Hall

> 
> 
> 
> Dave Hall (address@hidden) wrote*:
> >
> >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
> >>
> >
> 
> 
> 
> _______________________________________________
> 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>