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