Re: [phplib] [Fwd: [PHP-PEAR] Merging PHPLIB into PEAR] From: Alexander Aulbach (ssilk <email protected>)
Date: 01/28/01

On Thu, 18 Jan 2001, Kristian Koehntopp wrote:
}Different concepts. PEAR::DB tries to be a useful class all on
}its own. No class in PHPLIB tries that.

}The main idea of PHPLIB is that you have many pages, a web
}application, all of which use the same classes. PHPLIB
}encourages you to subclass the PHPLIB classes and overwrite the
}class variables with the defaults you need. On the pages where
}you need functionality, all you need to do is
}
} $db = new My_DB_Sql_Subclass();
}
}and you are set. All needed connection information is magically
}available, as it is the same on all your pages of a single
}application anyway. We need to teach this way of thinking to the
}PEAR people, it is an open issue, and a concept central to
}PHPLIB.

Hum, just had time to read a little bit in PHPLIB-list and found this
thread. Sorry, this is not a very actual reply. :)

PHPLIB is for big server development not very usable. Problems:
- different PHPLIB-Versions (cause of the concept of "everyone can do his
own class)
- bad programmers can missuse the described magic (change the api for his
own fun for example)
- In real life the "many pages" must be programmed by different
developpers and they all use other tools and libraries, one uses for
example PEAR::DB, the other uses pure mysql-API-calls...
- There is no "allround conceptional background" in PHPLIB. Currently
everyone makes changes, but there is no aim or rule, which tells him,
which is the correct direction.

These are "real life" examples of things I experienced, not things that
probably could be.

}The thing that varies from each use to use in a DB class is the
}query. That's why you can specify the query as a parameter to
}the constructor in newer instances of PHPLIB,
}
} $db = new My_DB_Sql_Subclass("select ...");
} while($db->next_record()) {
} do_something_with_record();
} }

In real life the User-DB is for example in the database USER, the data is
stored inside DATA, sessions are stored in TMP, the ads needs database AD,
authentication needs LDAP, permission-flags are stored in a database.

Cause every class in PHPLIB is tangled with others, a developer needs some
days to understand, how he can use PHPLIB to fit all his wishes. In this
time he also could program it by himself.

}It is of little use to specifiy connection parameters as
}constructor parameters, as these are essentially all the same in
}your web application, and should be specified only once, in your
}subclass definition.

I don't see any difference between PHPLIB local.inc:
<?

class bla extends DB_Sql
...
class blubb extends DB_Sql...
doozens lines of code ...
...
?>

and a configuration file like config.inc

<?

$dbblconnect="mysql://....";
$dbblubbconnect="mysql://...";
...

?> 

-- 

SSilk - Alexander Aulbach - Herbipolis/Frankonia Minoris

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>