Re: [Phpgroupware-developers] Information sharing between modules

[Dave Hall]

Hi Brian,

Brian Johnson <address@hidden> wrote:

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

It took me a while to understand classes.

> 
> 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 understand where you are coming from

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

I learnt quick solutions canbring me undone.  

If anyone else is interested in work on this let me know.  I won't have
anytime for a couple of weeks.  As this impacts on the api i think some
feedback from the core dev team would be useful.

Cheers

Dave

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