Re: [Phpgroupware-developers] Proposal to add inter-app linking system to API

[Brian Johnson]

I agree, however I'd like to get something into HEAD so that it can be used
and tested.

The existing code uses a link_id field so I proprose we leave it as it until
someone has  time/initiative to change it .. but it can be changed after it
has been accepted

It seems like there is no major objections (only minor things that can change
as the system evolves .. like all the apps) to starting with this code as a
first solution to interapp linking

I've lost track of HEAD status.  How does this proceed from the .16 infolog to
the API in HEAD?



Dave Hall (address@hidden) wrote:
>
> On Sat, 2004-06-19 at 06:52, Brian Johnson wrote:
> > What is you schema like for datamine?
> >
> > My proposal to use the infolog linking system uses one table like so:
> >
> >  link_id | link_app1 | link_id1 | link_app2 | link_id2 | link_remark |
> > link_lastmod | link_owner
> >
> ---------+-----------+----------+-----------+----------+-------------+--------------+------------
> >       39 | infolog   | 27       | timetrack | 3401     |             |
> > 1086901171 |         45
> >       40 | infolog   | 22       | timetrack | 1990     |             |
> > 1086901171 |         45
> >       41 | infolog   | 22       | timetrack | 1176     |             |
> > 1086901171 |         45
> >
> >
>
> IMHO link_id is not needed.  Compound pk of link_app1, link_id1,
> link_app2,link_id2, link_owner would ensure it is always unique.
>
> Cheers
>
> Dave
>
>
> > Joseph Engo (address@hidden) wrote:
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > I was not recommending datamine for purposes of direct use.  It won't
> > > work, the nextgen API is very different.  However, many of the
> > > concepts can be backported.
> > >
> > > The tables are different as well.  You can get away with adding a
> > > dm_type to each application, and adding a datamine table.  If you use
> > > things with a location tag, it will make upgrades in the future possiable.
> > >
> > > We will be moving to nextgen after 1.0 is released.
> > >
> > > Yes, most if not all apps are being rewritten, its to take advantage
> > > of a better API and structure.  Plus, many apps like TTS need a
> > > rewrite BADLY.
> > >
> > > Brian Johnson wrote:
> > >
> > > | The biggest issue that I have with that is that it won't be
> > > | available
> > > until
> > > | nextgen is adopted .. and nextgen requires a rewrite of many of the
> > > |
> > > apps if I
> > > | understand correctly (so will be a nasty transition from an
> > > | existing installation)
> > > |
> > > | If the nextgen code uses the same table schema and data (with the
> > > addition of
> > > | a dm_type field and it's data), then we could add the infolog link
> > > system to
> > > | head and replace the code with the nextgen datamine code when the
> > > switch to
> > > | nextgen occurs
> > > |
> > > |
> > > |
> > > | Joseph Engo (address@hidden) wrote:
> > > |
> > >
> > > | Take a look at what I did with datamine in nextgen.  (There is also
> > > |  some very brief docs in wiki about it).  The code is a little
> > > | messy right now, but the concepts are good.  This will be a little
> > > | harder to pull off in HEAD, but its possiable.
> > > |
> > > | The greatest thing about datamine, is symbolic and hard links.
> > > | They are very powerfull and make life much easier.
> > > |
> > > | Brian Johnson wrote:
> > > |
> > > | | This has been bounced around before and I think everyone agrees |
> > > | that it has potential for being very useful | | Since there hasn't
> > > | been much activity on it and I've been playing | with infolog and
> > > | it's linking system, I propose that the infolog | linking system
> > > | (which is already in a separate class under the | infolog
> > > | directory) be moved into the api. | | Basically, it uses one table
> > > | (phpgw_links) to maintain links | between records in two apps. | |
> > > | A hook is provided by each app that wants to allow linking to it's
> > > | | records | | Another hook is provided by each app that wants to
> > > | allow listings | of it's records by other apps. | | I have used it
> > > | for timetrack and it works. | | I envision the ability of multiple
> > > | apps to become different views | into the data and this should lead
> > > | to that. | | Consider this email as a proposal to the coordination
> > > | team (if that | is necessary). | | | |
> > > | _______________________________________________ |
> > > | Phpgroupware-developers mailing list |
> > > | address@hidden |
> > > | http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> > > |
> > > |
> > >
> > > _______________________________________________
> > > Phpgroupware-developers mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> > >
> > >
> > >
> > >
> > >
> > > | _______________________________________________
> > > | Phpgroupware-developers mailing list
> > > | address@hidden
> > > | http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> > >
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.2.3 (MingW32)
> > > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> > >
> > > iD8DBQFA0y9F/AzmiD/o0voRArZHAJ0UE01PLFrwr1nx4pCVlm+i9Qt43gCeMxko
> > > I6aK0JyoU1tXGlCOa0JrggY=
> > > =JfQz
> > > -----END PGP SIGNATURE-----
> > >
> > >
> > >
> > > _______________________________________________
> > > Phpgroupware-developers mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Phpgroupware-developers mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
>
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
>
>