Re: [Phpgroupware-developers] Information sharing between modules

[Brian Johnson]

NOW THAT'S THE GLOBAL SYSTEM I WAS LOOKING FOR - yes I'm excited

Nice and simply too, a four field table

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



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
>>
>