Re: [phpGroupWare-developers] Nested db-objects

[Dave Hall]

On Sat, 2008-05-24 at 16:23 +0200, Maât wrote:
> Sigurd Nes a écrit :
> > As Maât very elegantly wrote (he is my hero) - we need the freedom to do 
> > studid things.
> >   
> 
> Please Sigurd, don't try to use my words for more than i intended to 
> mean (sorry i'm going to loose the "hero" status)
> 
> I explained that framework should allow to do things... even stupid but 
> i also said that was for M. Doe apps... for core apps i consider doing 
> things stupidly should make apps be granted a quality label like "low 
> level" and/or provided as a third party separate package instead of 
> included in core phpgw package.
>  
> A framework allowing to do things in a "quick-and-dirty" manner would 
> bring more people willing to code tiny apps *for themselves* and later 
> perhaps bring a few valuable and "quality aware" developers... but for 
> core apps we should set high quality standards as a requirement.
> 
> i bet nobody here wants slow and ressource consuming apps in phpgw that 
> wouldn't give a good example :)
> 
> That means db cloning shoud be avoided like plague in core apps (even if 
> not hard locked) and only accepted in specific cases when this is the 
> best (or least ugly) solution.
> 
> > And it is not good when it - BANG! - stop working - and we have to 
> > speed-rewrite large portions of the code.
> >   
> 
> The brutal way of switching from one option to another could have been 
> replaced by a prior notice and a negociated deadline so that everybody 
> can study the side effects and plan the rework in a reasonable, NOT 
> INFINITE, time.

This is not as Sigurd suggests a recent change.  The change was merged
into the phpGW tree 6 months ago[1], from the resight tree.  For an even
longer period of time I have been explaining to Sigurd that the way he
uses db objects is broken and needs to be fixed.  Sigurd continued to
implement this anti pattern.

Based on my review of the property code (and other places where the db
object is cloned) it is completely unnecessary.  By properly separating
the storage and business logic this wouldn't be a problem.

It also should be noted that trunk is for development.  Things change,
that is what happens with development.  phpGroupWare is pre 1.0, that
means that anything can and does change.  Once we get to 1.0 we should
have a stable API. 1.2 will break somethings, 2.0 will break backward
compatibility.  This is normal, in both FOSS and proprietary software
development.

I think we can consider delaying the branching by 1 week, until Sunday
8 June 2008 at 1200UTC to allow Sigurd to finish the refactoring of his
code.  No further extension is reasonable.  If we keep on finding
issues/reasons to delay this then we will never get the release out.

Cheers

Dave


[1]
http://svn.savannah.gnu.org/viewvc/trunk/phpgwapi/inc/class.db.inc.php?root=phpgroupware&r1=18041&r2=18358