Re: [phpGroupWare-developers] Ideas for phpgw / RFC

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


Maât a écrit :
> Le 27/01/2010 15:15, Benoit Hamet a écrit :
>> Hi Maat,
>>
>> Maât a écrit :
>>   
>>> 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 :)
> 
> 
>>   
>>>> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
> 
>