Ideas for phpgw / RFC

[Caeies]

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.

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.

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

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.

Happy Hacking,

Caeies

[Maât]

Post by Caeies
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).

Hi Caeies,

Cool :)

Post by Caeies
I have a proposition for third-party libraries that we are using
We can add in phpgwapi/ a new directory call lib/thirdparty and modify
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.

Well isolate third party components is imho a really good idea

But i have a problem with CreateObject : It breaks code analysis and
object tracking tools :-(

And that is very harmful when it comes to debugging and reverse
engineering with graphic IDE such as EclipsePDT or Zend Studio or Komodo :-(

I'd rather see it replaced by something relying on new and constructors
with something like a "fully qualified phpgw objects names" system

Post by Caeies
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've played with doctrine which is really good...

i'd love to see something like this in phpgw !

Post by Caeies
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

Post by Caeies
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.
Happy Hacking,
Caeies

Eclipse PDT offers really cool merge/comparison features

Regards,
Maât

[Benoit Hamet]

Hi Maat,

Post by Maât

Post by Caeies
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).

Hi Caeies,
Cool :)

Post by Caeies
I have a proposition for third-party libraries that we are using
We can add in phpgwapi/ a new directory call lib/thirdparty and modify
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.

Well isolate third party components is imho a really good idea
But i have a problem with CreateObject : It breaks code analysis and
object tracking tools :-(
And that is very harmful when it comes to debugging and reverse
engineering with graphic IDE such as EclipsePDT or Zend Studio or Komodo :-(
I'd rather see it replaced by something relying on new and constructors
with something like a "fully qualified phpgw objects names" system

Well, I agree with you, we should deprecate CreateObject in favor of
autoload + new. Or I'm not clear ? :).

Post by Maât

Post by Caeies
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've played with doctrine which is really good...
i'd love to see something like this in phpgw !

Post by Caeies
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

Post by Caeies
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.
Happy Hacking,
Caeies

Eclipse PDT offers really cool merge/comparison features

That's not the point ... the point is keeping track of merges, so if
another dev want to do some of them, he is able to do it, without the
need to use the exact same tool, with your history :).

Regards,

Caeies.

Post by Maât
Regards,
Maât
_______________________________________________
phpGroupWare-developers mailing list
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers

[Maât]

Post by Benoit Hamet
Hi Maat,

Post by Maât
But i have a problem with CreateObject : It breaks code analysis and
object tracking tools :-(
And that is very harmful when it comes to debugging and reverse
engineering with graphic IDE such as EclipsePDT or Zend Studio or Komodo :-(
I'd rather see it replaced by something relying on new and constructors
with something like a "fully qualified phpgw objects names" system

Well, I agree with you, we should deprecate CreateObject in favor of
autoload + new. Or I'm not clear ? :).

We share the same point ov view it seems :)

Post by Benoit Hamet

Post by Maât

Post by Caeies
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.
Happy Hacking,
Caeies

Eclipse PDT offers really cool merge/comparison features

That's not the point ... the point is keeping track of merges, so if
another dev want to do some of them, he is able to do it, without the
need to use the exact same tool, with your history :).
Regards,
Caeies.

yes of course one should be able to use the tool he likes :)

either eclipse or svnmerge or whatever merge tool involved people will
choose indeed :)

i did not think otherwise

Bests,
Maât

[Benoit Hamet]

Hi all,

Following the discussion here, I plan to try to build the autoload
mechanism in my own branch. In first time, I will made it only working
for core apps and api.

I will be happy to discuss with those interested in the process.
After some quick&dirty search on the net, I plan to use the
slp_autoload_register (so we should be able to use other autoload
feature from thirdparty libs) on a special object dedicated to this
management. It seems to be two schools, one relying on name convention,
the other relying on loaded arrays. Since IMHO we should be able to use
the autoload feature, even for libraries that are not autoloaded, and as
we don't need the autoload feature to be "automatic", I plan to build a
static file containing the autoload infos that should be put in the svn.
This is, IMHO, the best compromise between flexibility and performances.
To help the migration, I will use the autoload feature first in
CreateObject function and then replace this function on a per need
basis. I will replace the old stuff from $GLOBALS[] that was requesting
inclusion of portion of the API in functions.inc.php.

Regards,

Caeies.

Post by Maât

Post by Benoit Hamet
Hi Maat,

Post by Maât
But i have a problem with CreateObject : It breaks code analysis and
object tracking tools :-(
And that is very harmful when it comes to debugging and reverse
engineering with graphic IDE such as EclipsePDT or Zend Studio or Komodo :-(
I'd rather see it replaced by something relying on new and constructors
with something like a "fully qualified phpgw objects names" system

Well, I agree with you, we should deprecate CreateObject in favor of
autoload + new. Or I'm not clear ? :).

We share the same point ov view it seems :)

Post by Benoit Hamet

Post by Maât

Post by Caeies
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.
Happy Hacking,
Caeies

Eclipse PDT offers really cool merge/comparison features

That's not the point ... the point is keeping track of merges, so if
another dev want to do some of them, he is able to do it, without the
need to use the exact same tool, with your history :).
Regards,
Caeies.

yes of course one should be able to use the tool he likes :)
either eclipse or svnmerge or whatever merge tool involved people will
choose indeed :)
i did not think otherwise
Bests,
Maât
_______________________________________________
phpGroupWare-developers mailing list
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers

[Benoit Hamet]

Replying to myself ...

Post by Caeies
Hi all,
Following the discussion here, I plan to try to build the autoload
mechanism in my own branch. In first time, I will made it only working
for core apps and api.
I will be happy to discuss with those interested in the process.
After some quick&dirty search on the net, I plan to use the
slp_autoload_register (so we should be able to use other autoload
feature from thirdparty libs) on a special object dedicated to this
management. It seems to be two schools, one relying on name convention,
the other relying on loaded arrays. Since IMHO we should be able to use
the autoload feature, even for libraries that are not autoloaded, and as
we don't need the autoload feature to be "automatic", I plan to build a
static file containing the autoload infos that should be put in the svn.
This is, IMHO, the best compromise between flexibility and performances.
To help the migration, I will use the autoload feature first in
CreateObject function and then replace this function on a per need
basis. I will replace the old stuff from $GLOBALS[] that was requesting
inclusion of portion of the API in functions.inc.php.

I made first tests this afternoon. Just to see if it's doable or not ...
Well, this will not work as expected (out of the box of course :( )
since we are doing some tricky stuff in CreateObject and in included
files (like building the db object depending of the configuration in
header.inc.php, or the vfs, or accounts or contacts ...). So the changes
will be deeper than what I was thinking. At least with the "automated"
way of retrieving class infos... Dev idea's are welcome.
In my mind, I want to bootstrap the autoload chain (in setup too !) so
we are able to easily use our classes in every conditions ...

Regards.

Caeies.

Post by Caeies
Regards,
Caeies.

Post by Maât

Post by Benoit Hamet
Hi Maat,

Post by Maât
But i have a problem with CreateObject : It breaks code analysis and
object tracking tools :-(
And that is very harmful when it comes to debugging and reverse
engineering with graphic IDE such as EclipsePDT or Zend Studio or Komodo :-(
I'd rather see it replaced by something relying on new and constructors
with something like a "fully qualified phpgw objects names" system

Well, I agree with you, we should deprecate CreateObject in favor of
autoload + new. Or I'm not clear ? :).

We share the same point ov view it seems :)

Post by Benoit Hamet

Post by Maât

Post by Caeies
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.
Happy Hacking,
Caeies

Eclipse PDT offers really cool merge/comparison features

That's not the point ... the point is keeping track of merges, so if
another dev want to do some of them, he is able to do it, without the
need to use the exact same tool, with your history :).
Regards,
Caeies.

yes of course one should be able to use the tool he likes :)
either eclipse or svnmerge or whatever merge tool involved people will
choose indeed :)
i did not think otherwise
Bests,
Maât
_______________________________________________
phpGroupWare-developers mailing list
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers

_______________________________________________
phpGroupWare-developers mailing list
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers

[Sigurd Nes]

Post by Benoit Hamet
Replying to myself ...
I made first tests this afternoon. Just to see if it's doable or not ...
Well, this will not work as expected (out of the box of course :( )
since we are doing some tricky stuff in CreateObject and in included
files (like building the db object depending of the configuration in
header.inc.php, or the vfs, or accounts or contacts ...). So the changes
will be deeper than what I was thinking. At least with the "automated"
way of retrieving class infos... Dev idea's are welcome.
In my mind, I want to bootstrap the autoload chain (in setup too !) so
we are able to easily use our classes in every conditions ...

I don't know if this is in your line of thinking - but I have a version of the
db-object that uses either pdo or adodb - based on settings in the header.inc.php.

Also there is an optional feature of delaying the connect upon creating the
object - this way I am able to connect to a different database on an different
platform mid-session for seamless integration.

However - with the current setup - I am stuck with the chosen abstraction within
the session.


Regards

Sigurd

[Sigurd Nes]

Post by Caeies
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
We can add in phpgwapi/ a new directory call lib/thirdparty and modify
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.

Post by Caeies
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

Post by Caeies
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

Post by Caeies
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