Re: [Phpgroupware-developers] Information sharing between modules

[Brian Johnson]

I'm afraid I'm not the right guy to develop classes - I don't even know how to 
use
them yet

I just wanted to make sure the concept was covered and had a solution because I 
want
to see more module integration and am likely going to take advantage of it

I'm a code hacker (modifying other people's code to add features I want), rather
than a programmer.  I go for the quick solution with the tools I know how to use
rather than spend a lot of time on how it should be done (unless like this, I 
want
to make sure that my hacks tie in with other people's work)



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