Re: Nested db-objects

Maât <[email protected]>
Newsgroups gmane.comp.web.phpgroupware.devel
Message-ID <[email protected]>
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.


> A successfull implementation will (and already has)  provide resources back into the project - so that should be a good thing for phpgroupware in the long run.
>   

(Sorry my english is too poor and i didn't understand that)

> I will take all advice on code style seriously - but it shouldn't be forced - and it can't be all implemented at once.
>   

Once again, i said it shouldn't be locked *at code level* .... but if i 
didn't make myself clear it should be :

-- discouraged for  M. Doe or M. Smith app
-- nearly forbidden for standard apps

AND DEVELOPERS (me included) SHOULD LISTEN AND ACCEPT QUALITY TEAM 
REQUIREMENTS AND COMPLY WITH THEM

> So - can I please have the nested db-objects?
>
> Regards
>
> Sigurd
>   
If you ask me (but i'm just giving my point of view) i would say : 
*temporarily* yes with the following conditions :

1) we should rewiew/clean/optimize rather quickly the code modifications 
you suggested so that clone creation and clone release are well 
controlled (and the number of clones limited) or better if possible : 
replace the cloning by a cleverer approach that allows multiple requests 
to be parsed without conflict (and then plan for a replacement of clones 
where they were used).

2) we should track very seriously :
-- un-needed clones (created and not used)
-- cases where a slight code rework could avoid the clone approach
-- too early cloning
-- too late releasing

3) We should fix the above cases in apps (included ged and property) 
with a rather high priority in a reasonable time.

regards,
Maât
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.