RE: RE: [Phpgroupware-developers] Re: phpGroupware database and u ml d ocumentation in wiki?

[Brian Johnson]

I don't think I'm going out on a limb to say that most of us consider 
addressbook
and calendar to be part of the core system that other apps would/should tie 
into better.

As for duplicated tables with the same info, I know for certain that timetrack
duplicates parts of addressbook, accounts, and hr because those apps don't 
provide
what timetrack needs in their current form.

A standard inter-app linking system is needed.  The linking system included with
infolog (please relaize that I'm talking about the code behind infolog and not 
just
the ui .. although that is good too for viewing and creating links) is the most
flexible and easiest to standardize system.  It basically boils down to one 
table.
It should be used.


Michael Dean (address@hidden) wrote:
>
>On Fri, 2003-06-13 at 04:23, Kai Hofmann wrote:
>> phpgw is an api and a database with basic functionality for other
>> groupware modules that depend on the api and the database.
>> The data is important for a groupware because a groupware
>> integrates data instead of having a single application for each
>> work process.
>
>InfoLog is a good example of this.  While you can work with the data
>that InfoLog integrates in separate modules, InfoLog brings it all
>together.
>
>You need to remember that the API is the BASE of phpGW.  User and group
>management, database abstraction, sessions, SMTP, NNTP, etc are all
>vital core components to groupware.  The "core" applications themselves
>should depend on the API, but not each other.  You shouldn't need to
>install tables that lend themselves only to modules you may or may not
>be using.
>
>> > > When having a whole database as in my example - you don't need
>> > > something like infolog for the data communication (between the
>> > > modules).
>
>See above ;-)
>
>> > Yes but phpGW is more than a db.  I think the db can be worked on and
>> > tweaked a little, but the model can not expect that there
>> > will be app X
>> > installed for it to work.  phpGW is designed to be modular, with
>> > integration not a set collection of apps with inter dependencies.
>
>Yep - tweakage will come later this year.
>
>> Here are two points:
>>
>> 1) A database mainatiner is required - which task is to maintain the db api
>>    as well as the "central db-schema" (in cooperation with the module
>> mainatiners).
>
>I have indirectly volunteered to do this by taking over maintenance of
>the database classes and updating schema_proc as necessary.  I have
>identified changes in the classes as I work to integrate them with DCL,
>and these changes will roll back into phpGW.  As a side-benefit of using
>them in DCL (eating own dog food I guess), phpGW will gain Sybase
>support and possibly Oracle.
>
>> 2) The data is the important thing - thats for example the most import
>> concept of
>>    object orientation.
>>    So a new phpgw module can work on existing db tables/relations as well as
>> connect
>>    its own tables via new relations to the existing db (without any
>> problem).
>
>phpGW does this today.
>
>> As a result it would be possible to have different (for example adressbook)
>> modules
>> that are working on the same db tables/relations. One of these modules might
>> be more
>> simple and unse only a part of whats possible and the other might be more
>> complex and
>> add some extra data to the model.
>> The advantage is that you avoid redundant data and that you have a much
>> better
>> interaction between modules that need the same data (adress book and project
>> manager for example).
>
>Also does this today.  Just because the apps aren't there doesn't mean
>that the phpGW architecture needs to change.  InfoLog is a fine example
>of pulling different modules' data stores into a single interface/app.
>
>>
>> For the moment the proble (as you know) is that every module reinvents a
>> part of already existing (in the phpgw)
>> things.
>
>I disagree.  While the schema isn't perfect, I certainly don't see
>copies of tables being made to be application specific.
>
>> Btw. its no problem to install a complete database schema in a db and only
>> having one module that
>> works on a small part of it!
>
>Sure, but I wouldn't want to be the sucker to DBA it.  Especially
>installed in alongside other apps outside of phpGW (which would be
>common in Oracle installations or web hosting, for example)
>
>Mike
>
>
>
>_______________________________________________
>Phpgroupware-developers mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>

--
Brian Johnson
* This is where my witty signature line would be if I bothered to edit this 
line :) *