David wrote:
I found and interesting article, "Experience s of Using PHP in Large
Websites" (http://www.ukuug.org/events/linux2002/papers/html/php/) ,
which lists some issues with scaling PHP for larger projects. Worth
a read although it appears to be three years old.
Not really - the article is rather badly written, poorly justified, and in
several instances just plain wrong. I find it remarkable that someone could
produce so many words about PHP development without mentioning code
testing. (see recenet thread here regards typing / variable declaration).
The major issue I have had with PHP is a conflict in class names for
modules created by two project teams. We resolved this by prefixing
all class names with a module ID, ex. "ModuleName__<C lass Name>"
The only mistake I can see with this article is a statement that you
can only have one php.ini per server.
Who is using PHP for larger projects and how do you handle the naming
issue?
I have about 600,000 lines of PHP here, 6 programmers and between 1 and 3
web designers. The servers field about 3 million requests/day. Is that big?
I use a similar approach - any global symbol in an include file should be
prefixed by the file name e.g. file transact_db.inc .php might contain fn
transact_db_ini (), class transact_db, fn transact_db_que ry(), fn
transact_db_dic onnect()...
The namespace thing is an old chestnut in PHP circles. I had some time
recently to have a think about it and wrote my own namespace handler (in
PHP). Next time I have some time free I'll publish it somewhere.
The ,ost important advice I could give to anyone embarking on a large-scale
project using PHP would be:
- set strict style/naming guidelines - the PEAR ones are a useful starting
point
- use unit and integration testing
- don't worry about scalability - PHP has it in spades
HTH
C.
