Re: Ideas for phpgw / RFC

Sigurd Nes <[email protected]> Wed, 27 Jan 2010 22:54:23 +0100
Newsgroups gmane.comp.web.phpgroupware.devel
Message-ID <[email protected]>
Caeies wrote:
> Hi all,
> 
> I'm doing some fixes today, roughly checking for typos with an in house
> script that count occurrences of a var in a function (that's really
> really basic).
> 
> I have a proposition for third-party libraries that we are using
> straight from upstream :
> 
> We can add in phpgwapi/ a new directory call lib/thirdparty and modify
> our CreateObject function accordingly. The purpose of this is :
> 1) Easier maintenance of thirdparty software (licence issues, easy to
> identify what to change into the project, and what to change upstream in
> the thirdparty stuff, how to update it, etc ...)
> 2) better recognition / integration of others contributions in our project.
> 3) since we are now php 5, migrate the CreateObject function to use the
> auto load mechanism and using new as is, for better compatibility with
> thirdparty software.

I am all for separating the third-party.

As it currently works I am aware of three standard methods of including code:

phpgw::import_class('app.class');
createObject('app.class');
and
include_class('app', 'class', 'path/relative/to/app');

As I understand your proposition - you want to separate the thirdparty libs from 
our code - and tune the CreateObject function to use the code from its new home?

One probably still need a standardized wrapper to call the thirdparty code.

> 
> Next. I'm looking for the opportunity to use an ORM in phpgw (propel,
> doctrine, redbean, php-activerecord, ...) and doing here a RFC about it.

I'm interested

> 
> Next. Can I strongly suggest everyone commiting the code in our source
> tree to use English var names / db names / translation base / etc ...
> That's really easier for us to understand the code and it's philosophy ...
Agreed

> 
> Next. If you want to merge code from a branch or another, can I suggest
> the use of svnmerge scripts ? This will help us for merging back things
> instead of looking in the history for already done merges, etc ... I'm
> open to suggestion regarding other tools to manage the merge stuff.
> 
Examples?


Regards

Sigurd