phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joseph Engo
Subject: Re: [Phpgroupware-developers] Proposal to add inter-app linking system to API
Date: Sat, 19 Jun 2004 17:03:20 -0400
User-agent: Mozilla Thunderbird 0.6 (Windows/20040502)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dm_id | dm_location_from | dm_location_to | dm_type | dm_owner

Thats all you need.  The location follows this format, which would
need to be changed for HEAD to make use of it.

from:  notes.base.44
to:  infolog.base.12

For head, you can use this format:
from: notes.bonotes.44
to: infolog.bonotes.12

execObject('notes.bonotes.dm_get',44) Store the data in a global,
execute the hooks for datamine.  Then the hook for each app will
determine the display of each entry.

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
|
|
| Joseph Engo (address@hidden) wrote:
|

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

_______________________________________________
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

iD8DBQFA1KoX/AzmiD/o0voRAmZxAJ9ksJw++l7HPjNwCIl/fdiX9garjQCffFRV
q7DEHc/foqKns2ID+vmkaM8=
=d+JR
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]