Large Scale PHP Application Design Questions

[Jesse Burns]

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the long
run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

[Jerry Stuckle]

Jesse Burns wrote:

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the long
run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

Don't worry about performance until it becomes a problem. 1000 visitors
a day is nothing.

Design a good site and use good programming practices. Things like
templating engines have their use - mostly in rapid development. They
don't necessarily make maintenance any easier or harder.

But also, this may not be the best site for you to cut your teeth on.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[larry]

Don't expect everything to go just right the first time. Working on a
big project myself (as I learn PHP) I've repeatedly had to go back and
recode finished sections when I ran into a roadblock or potential
design flaw.

If its something that's going to grow, look early-on into how to
organize your files and present your page(s) - partly for security
partly for sanity.

Name your variables, fields, and functions well ( I use: table_field
for all DB fields, and local variables are pretty descriptive too)

Format your code (the PEAR formatting tips are an excellent start).

Setup function libraries for your POST, GET, and DB input/output calls
(just about anything else that gets repeated) so you have just one
place to refine data filtering as you progress.
Find and use a good IDE (I use Quanta on Linux) it does sooo many
great things like project-wide search-replace.

Also PHPMyAdmin is THE BEST utility for doing MySQL development work,
(you should still know how to do MySQL from the MYSQLprompt/ and
direct calls) PHPMyAdmin just makes MySQL work go so much quicker.

[C. (http://symcbean.blogspot.com/)]

On 17 Oct, 03:36, "Jesse Burns" <[e-mail]:

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

This is not a huge volume.

>
I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

Think about version control before you start writing the code - it'll
make life a lot simpler in the long run. Similarly plan the testing
ahead - I'd recommend going for continious integration testing as a
must have and unit testing as a nice to have.

Using abstraction anywhere is a trade-off between productivity and
performance - IME having an abstraction layer does not really make
code portable across DBMS. I'm not a fan of pure ORM but encapsulating
data sources as objects (using a factory pattern) can make portability
less painful and make for better code management.

As Larry suggests, stick to a good, standard style guide. Document
your code properly - and find a code document tool which suits you
(PHPDocumentor, PHPXRef....).

Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

Get your DNS registration seperately from your hosting - if you tie
them both to the same supplier you could end up being held hostage by
their provision plans if you really do hit the big time.

The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

HTH

C.

[Erwin Moller]

C. (http://symcbean.blogspot.com/) schreef:

(A few comments)

>
Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

That is good advise.

I always include 1 file everywhere in my project too.
Put stuff like this into it:

$newincludepath =
get_include_path().PATH_SEPARATOR.'/whatever/myproject/www/includes';
ini_set("include_path", $newincludepath );

Makes life a lot easier indeed, especially when you include other files
in your already included file (or more nesting).

>
When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

What?
I don't think that is good advise.
IMHO it is ALWAYS a good idea to use autoincrement PRIMARY KEYS on every
table when designing relational databases.

I do not see how this closes the door if you scale your app up to
multiple databases.
Care top explain?

The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

Hmm, I prefer writing my own code for excactly that reason! ;-)
It is VERY hard for a newbie to judge which code is good and which code
is bad.
Writing your own code increases your understanding of whatever problem
it is you are working on.

just my 2 cent.

Regards,
Erwin Moller

>
HTH

C.

--

[Erwin Moller]

Michael Vilain schreef:

In article <48*********************@news.xs4all.nl>,
Erwin Moller
<Si******************************************@spam yourself.comwrote:

>C. (http://symcbean.blogspot.com/) schreef:

(A few comments)

>>Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

That is good advise.

I always include 1 file everywhere in my project too.
Put stuff like this into it:

$newincludepath =
get_include_path().PATH_SEPARATOR.'/whatever/myproject/www/includes';
ini_set("include_path", $newincludepath );

Makes life a lot easier indeed, especially when you include other files
in your already included file (or more nesting).

>>When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

What?
I don't think that is good advise.
IMHO it is ALWAYS a good idea to use autoincrement PRIMARY KEYS on every
table when designing relational databases.

I do not see how this closes the door if you scale your app up to
multiple databases.
Care top explain?

>>The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

Hmm, I prefer writing my own code for excactly that reason! ;-)
It is VERY hard for a newbie to judge which code is good and which code
is bad.
Writing your own code increases your understanding of whatever problem
it is you are working on.

just my 2 cent.

Regards,
Erwin Moller

>>HTH

C.

--

Hi Michael,

I've also only coded small projects and not bothered to use anything but
autoincremented primary keys for my tables that needed them. But I can
see schreef's point for MySQL databases.

His name is NOT schreef.
I am from the Netherlands and my usenetclient is in Dutch.
'Schreef' means 'wrote'.
His nick here is 'C'.
Sorry for the confusion (I'll try to teach my thunderbird to speak
english soon.) ;-)
MySQL doesn't really have the

behind-the-scenes ability to put it's storage in alternate locations.
Then again, I haven't managed large MySQL installations (e.g.
multi-million row tables). There may be a way to store such files
distributed around a filesystem, but I'm not aware of it. Oracle and
other production-class DBMS's allow for allocating tablespaces whereever
you want. It was a common thing to add disks to a server and setup
Oracle data on them when I managed Solaris systems.

Yes, my favorite Postgres can also do that.
And besides that: If you use multiple database (not just a larger
filesystem), you can also still use a (centrally distibuted)
autoincrement PK.

>
So, I think schreef's workaround for this shortcoming is to use
multi-system databases. schreef, can you explain what you mean and why?

C (alias 'schreef' from now on ;-) ), generally knows very well what he
is talking about, so I am curious too. :-)

Regards,
Erwin Moller

[Norman Peelman]

Michael Vilain wrote:

In article <48*********************@news.xs4all.nl>,
Erwin Moller
<Si******************************************@spam yourself.comwrote:

>C. (http://symcbean.blogspot.com/) schreef:

(A few comments)

>>Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

That is good advise.

I always include 1 file everywhere in my project too.
Put stuff like this into it:

$newincludepath =
get_include_path().PATH_SEPARATOR.'/whatever/myproject/www/includes';
ini_set("include_path", $newincludepath );

Makes life a lot easier indeed, especially when you include other files
in your already included file (or more nesting).

>>When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

What?
I don't think that is good advise.
IMHO it is ALWAYS a good idea to use autoincrement PRIMARY KEYS on every
table when designing relational databases.

I do not see how this closes the door if you scale your app up to
multiple databases.
Care top explain?

>>The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

Hmm, I prefer writing my own code for excactly that reason! ;-)
It is VERY hard for a newbie to judge which code is good and which code
is bad.
Writing your own code increases your understanding of whatever problem
it is you are working on.

just my 2 cent.

Regards,
Erwin Moller

>>HTH

C.

--

I've also only coded small projects and not bothered to use anything but
autoincremented primary keys for my tables that needed them. But I can
see schreef's point for MySQL databases. MySQL doesn't really have the
behind-the-scenes ability to put it's storage in alternate locations.
Then again, I haven't managed large MySQL installations (e.g.
multi-million row tables). There may be a way to store such files
distributed around a filesystem, but I'm not aware of it. Oracle and
other production-class DBMS's allow for allocating tablespaces whereever
you want. It was a common thing to add disks to a server and setup
Oracle data on them when I managed Solaris systems.

MySQL5.1 has tablespaces and the ability to store tables in different
places via the: DATA DIRECTORY='/full/path', and INDEX
DIRECTORY='/full/path/' directives.

http://dev.mysql.com/doc/refman/5.1/...ate-table.html

....about half way down the page. Some catches, haven't tried it myself.

So, I think schreef's workaround for this shortcoming is to use
multi-system databases. schreef, can you explain what you mean and why?

--
Norman
Registered Linux user #461062

[Jesse Burns]

Thanks for the feedback folks, it's much appreciated.
"Jesse Burns" <jb*******@jbwebware.comwrote in message
news:gd**********@aioe.org...

I'm about to start working on my first large scale site (in my opinion)
that will hopefully have 1000+ users a day. ok, this isn't on the
google/facebook scale, but it's going to be have more hits than just
family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the
long run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc...
actually use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like
to have as much original code as possible, that's why I'm not even
considering using a framework (I've dabbled a bit with CakePHP and ZF), so
I won't bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB
calls (going to use MySQL until I find it no longer suites my needs) would
be the most efficient approach.

I do plan on separating Data/Business/Presentation logic to make
maintenance easier, so that's the only reason I'm considering using a
Template engine to separate the Business/Presentation layers, and then
either PDO, ADOdb or PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to
separate the Business/Presentation layers, while using my own home brewed
DB class as the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

[Hugh Oxford]

Jesse Burns wrote:

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Although I agree with other commentators, I would say that for really
heavyweight stuff don't start with MySQL, but PostGres.

I wish I had started with Postgres on my main project.

[Jerry Stuckle]

Hugh Oxford wrote:

Jesse Burns wrote:

>I'm about to start working on my first large scale site (in my
opinion) that will hopefully have 1000+ users a day. ok, this isn't on
the google/facebook scale, but it's going to be have more hits than
just family and friends.

Although I agree with other commentators, I would say that for really
heavyweight stuff don't start with MySQL, but PostGres.

I wish I had started with Postgres on my main project.

Although PostGres is also a good database, MySQL is quite capable with
large projects.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jesse Burns]

That's funny, I've been comparing the differences between MySQL and Postgres
today after the above feedback.

I'm still looking into it, but it's a good thing to be aware of.

I also think that if I use proper encapsulation in my database class, then
if I choose to switch db's, it will be all that much easier as I will
hopefully only have to change the included db class that I create.

To tell you the truth, I don't see it being all that easy with proper
encapsulation, as if I do move from one db to another, it will probably be
because of features/design differences between db's, and that it will be a
lot more than just changes the connect info and some SQL syntax.

But this is a learning experience, and I should be familiar with my options
before making the dive, while still in the design phase, so I can make an
informed decision.

Once again, thank you everyone for the great input!

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gd**********@registered.motzarella.org...

Hugh Oxford wrote:

>Jesse Burns wrote:

>>I'm about to start working on my first large scale site (in my opinion)
that will hopefully have 1000+ users a day. ok, this isn't on the
google/facebook scale, but it's going to be have more hits than just
family and friends.

Although I agree with other commentators, I would say that for really
heavyweight stuff don't start with MySQL, but PostGres.

I wish I had started with Postgres on my main project.

Although PostGres is also a good database, MySQL is quite capable with
large projects.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[FutureShock]

Jesse Burns wrote:

That's funny, I've been comparing the differences between MySQL and Postgres
today after the above feedback.

I'm still looking into it, but it's a good thing to be aware of.

I also think that if I use proper encapsulation in my database class, then
if I choose to switch db's, it will be all that much easier as I will
hopefully only have to change the included db class that I create.

To tell you the truth, I don't see it being all that easy with proper
encapsulation, as if I do move from one db to another, it will probably be
because of features/design differences between db's, and that it will be a
lot more than just changes the connect info and some SQL syntax.

But this is a learning experience, and I should be familiar with my options
before making the dive, while still in the design phase, so I can make an
informed decision.

Once again, thank you everyone for the great input!

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gd**********@registered.motzarella.org...

>Hugh Oxford wrote:

>>Jesse Burns wrote:
I'm about to start working on my first large scale site (in my opinion)
that will hopefully have 1000+ users a day. ok, this isn't on the
google/facebook scale, but it's going to be have more hits than just
family and friends.
Although I agree with other commentators, I would say that for really
heavyweight stuff don't start with MySQL, but PostGres.

I wish I had started with Postgres on my main project.

Although PostGres is also a good database, MySQL is quite capable with
large projects.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

OT: Since you are diving into a large project and will most likely be
visiting, posting and replying here from time to time, some friendly
advice, please don't top post.

Good Luck
Scotty

[Beauregard T. Shagnasty]

FutureShock wrote:

OT: Since you are diving into a large project and will most likely be
visiting, posting and replying here from time to time, some friendly
advice, please don't top post.

Trimming also helps.

--
-bts
-Friends don't let friends drive Windows

[Jesse Burns]

"FutureShock" <fu**********@att.netwrote in message
news:am*****************@flpi149.ffdc.sbc.com...

Jesse Burns wrote:

>That's funny, I've been comparing the differences between MySQL and
Postgres today after the above feedback.

I'm still looking into it, but it's a good thing to be aware of.

I also think that if I use proper encapsulation in my database class,
then if I choose to switch db's, it will be all that much easier as I
will hopefully only have to change the included db class that I create.

To tell you the truth, I don't see it being all that easy with proper
encapsulation, as if I do move from one db to another, it will probably
be because of features/design differences between db's, and that it will
be a lot more than just changes the connect info and some SQL syntax.

But this is a learning experience, and I should be familiar with my
options before making the dive, while still in the design phase, so I can
make an informed decision.

Once again, thank you everyone for the great input!

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gd**********@registered.motzarella.org...

>>Hugh Oxford wrote:
Jesse Burns wrote:
I'm about to start working on my first large scale site (in my
opinion) that will hopefully have 1000+ users a day. ok, this isn't on
the google/facebook scale, but it's going to be have more hits than
just family and friends.
>
>
Although I agree with other commentators, I would say that for really
heavyweight stuff don't start with MySQL, but PostGres.

I wish I had started with Postgres on my main project.

Although PostGres is also a good database, MySQL is quite capable with
large projects.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

OT: Since you are diving into a large project and will most likely be
visiting, posting and replying here from time to time, some friendly
advice, please don't top post.

Good Luck
Scotty

Will do, thanks for the friendly heads up :-)

[Hugh Oxford]

Jerry Stuckle wrote:

>I wish I had started with Postgres on my main project.

Although PostGres is also a good database, MySQL is quite capable with
large projects.

To me it's not so much about the scalability or performance of the
RDBMS, but about things like clustering and replication.

[Jerry Stuckle]

Hugh Oxford wrote:

Jerry Stuckle wrote:

>>I wish I had started with Postgres on my main project.

Although PostGres is also a good database, MySQL is quite capable with
large projects.

To me it's not so much about the scalability or performance of the
RDBMS, but about things like clustering and replication.

But MySQL handles clustering and replication quite well, thank you.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Hugh Oxford]

la***@portcommodore.com wrote:

Find and use a good IDE (I use Quanta on Linux) it does sooo many
great things like project-wide search-replace.

I agree about Quanta, it's great, my bread and butter. Don't forget you
can use fish to open projects over ssh.

For ajax I've been using Xajax, it's fantastic, really robust, well
documented.

Another thing I do is I have a classpath directory and I use __autoload().

What this means is that if I have a class called FooClass I create a
file called FooClass.php and drop it in the classpath directory. Then,
if I want a new object of that class it's a simple case of $obj_FooClass
= new FooClass. Then I have a library of all my code logically ordered.

I would also recommend phpxref which goes through all your code and
cross references it; you can search for functions, classes, vars etc. It
gives you a great view of what's going on and is great if you ever have
to work on code you're unfamiliar with.

[Lawrence Krubner]

Jesse Burns wrote:

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the long
run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

I wouldn't think of 1,000 people a day as a large scale site. Maybe
10,000 a day. Certainly 100,000 a day.

I'd suggest using one of the frameworks to help guide you, such as
CakePHP, Symfony or CodeIgniter. They have the advantage of answering
certain tough architectural problems for you (templting, database
abstraction, etc). But if you are just learning PHP, then those
frameworks might be over your head.

[Lawrence Krubner]

la***@portcommodore.com wrote:

Don't expect everything to go just right the first time. Working on a
big project myself (as I learn PHP) I've repeatedly had to go back and
recode finished sections when I ran into a roadblock or potential
design flaw.

If its something that's going to grow, look early-on into how to
organize your files and present your page(s) - partly for security
partly for sanity.

Name your variables, fields, and functions well ( I use: table_field
for all DB fields, and local variables are pretty descriptive too)

To follow on with that, I'd suggest verbose method and variable names. I
like the idea, which the agile-programming community has advanced, that
it is better to have verbose method names than to write a lot of
comments. As they say "Whereas you would write a comment, we write a
method."

Some people hate this idea, but for me, I find that when I come back to
code that I wrote a year ago, variable names like this help me remember
what I was trying to do:

$stringOfHtmlForFormToBeBuiltUpInTheFollowingLoop = "";

[Jesse Burns]

I just wanted to respond to all of this great feedback. I've only been this
quiet because every new post gives me one more view point to ponder.

First of all, I should point out that I'm self taught and have had no
programming classes to speak of.

First of all, I've been programming with PHP for 4 years, but I've mainly
been creating plugins for the e107 CMS in a procedural style. So I'm not
completely starting from scratch. But I have been using 3rd party
plugins/libraries for database abstraction and templating systems, and I
need to improve on my OOP.

As I am going to add my code to my portfolio (local companies don't seem
that impressed when I give them a few plugins as example code), I've decided
to home brew everything. I feel I'll learn more along the way as well.

Like I've said, I've used CakePHP and the Zend Framework, but that's not
going to teach me some of the more advanced programming principles (it is a
great example of how others do it though, so it definitely is a great
learning experience).

A lot of my object oriented experience (pretty much most of it actually)
comes from the book "How to Program: C++", which is what they use in the
local universities. The edition I have starts using OOP and Design right
away, so I didn't get stuck in the procedural way of things from the get-go.

I do believe (and have been practicing) that all class attributes
(variables) should be private, using setters/getters to access them. The
main reason for this is encapsulation, which makes maintenance so much
easier.

For example, I'm creating my DB class right now. If I need to make any
adjustments to how data is processed, all I have to do is change the DB
class and not all of the DB calls in my application code.

So when I feel comfortable that all of the database calls are working the
way I want, I can then create a validation class and filter all of my input
from forms and use those calls in my DB class. This way, when I'm creating
my application, all I have to do is use my DB class to insert data, and feel
confident that the validation class will filter input correctly. And if it
doesn't, all I have to do is alter the validation class and leave the DB
class and all of it's calls alone.

As long as I keep the DB and validation class's interface flexible, I should
rarely have to change my applications code (although I know that a first
draft will always need alterations, just hopefully not too many).

I've also decided to use the Zend Framework's Coding Standards, so all of my
private attributes start with an underscore: _dbResult.

Another thing that book taught me was to keep all of your attributes (public
and private) at the bottom of your class, because when you look at a class
later on your most likely going to be looking at the interface, rather than
the data your working on (I know that's not always the truth at all, but
once you define attributes, for the most part you're going to leave them
alone).

I've also decided to keep to a strict naming convention regarding
file/class/method/attribute names. I do plan on being the stranger to my
code in a few months time, and also hope that one day I can put a team of
developers together to continue development, and if I already have a proper
coding standard in place, it will make it that much easier for other
developers to join the project.

I've also included my "includes" folder in php's include_path, which was a
great suggestion, thanks. I have one question on that. My "includes" folder
is located outside of my doc_root, but since it's in the include_path in my
php.ini file, can people still access it that don't have root privileges?

I know that I'm not thinking of everything that I'll need in the future, but
I hope that I have enough knowledge at this time to make changes in the
future as painless as possible.

I've also heard (and believe) that the likelihood of throwing away the first
draft and having to start again as you learn what works and what doesn't
work in large projects like this, is a big likelihood. And that's fine with
me as long as I'm learning in the process.

I know I haven't touched on a few suggestions posted here, but that's
because I'm still mulling them over and doing my research.

Once again, I'd like to thank everyone for their feedback. It is much
appreciated.

[larry]

On Oct 22, 10:36 am, "Jesse Burns" <[e-mail]:
[snip]

>
I've also included my "includes" folder in php's include_path, which was a
great suggestion, thanks. I have one question on that. My "includes" folder
is located outside of my doc_root, but since it's in the include_path in my
php.ini file, can people still access it that don't have root privileges?

You can set an .htaccess file to restrict anyone outside from
accessing files in the folder except localhost (or something to that
affect) so include will work but not user links (I just learned about
that one, have to re-arrange some files...)

I know that I'm not thinking of everything that I'll need in the future, but
I hope that I have enough knowledge at this time to make changes in the
future as painless as possible.

....

I know I haven't touched on a few suggestions posted here, but that's
because I'm still mulling them over and doing my research.

Heres a big tip, now that you have a good beginning of dos and donts,
START WRITING CODE!

Research and theory are nice for a lunch or evening conversation but
practice is where you will actually get your skills polished and
things get done. Some of this stuff may not work for you or you may
discover your own styles. Getting good at programming takes actually
programming a lot.

Also pain happens, regardless of what you know, just think of it as a
challenge, and know you will be getting some real-world hard-knocks
skills tackling those problems.

Once again, I'd like to thank everyone for their feedback. It is much
appreciated.

Sounds like you are off to a good start.

[Hugh Oxford]

Jerry Stuckle wrote:

>Prefix all your objects with $obj_

I disagree with this part. While it's important to give meaningful
names, I think $customer for a Customer object works well. Then use
something like $customerId for a customer's id (which is probably an
int). I just don't see a good reason to complicate things with $obj_
prefixes (plus it makes documentation that much harder when you have a
lot of objects prefixed that way).

It's a personal thing I suppose. I just like to know when I'm dealing
with an object.

>

>Objects should always have get and set methods for all variables.
IMHO, you should never access variables directly from outside the object.

Agreed - all variables should be private.

>The exception to this is using the __get magic method, which I have
found enormously useful. To give you an example, let's say you have a
customer object and you want to be able to get any property of the
customer eg. $obj_Customer->name and $obj_Customer->balance.

In this I somewhat disagree. I don't like the __get() and __set()
methods at all. It complicates the code.

>You can put a switch/case in the __get method so you can abstract away
anything behind the scenes. So $obj_Customer->name can bring back a
concatenation of firstname and lastname, $obj_Customer->balance can
call another object to do more work and return the balance, and so on.

Which is exactly what I'm referring to above. You don't need to use the
__get() method to do this if you have the methods already instantiated.

There's a time and a place for it. I never use __set because I want the
flexibility to be able to validate inputs to methods. In fact, I only
have one class which uses __get, but otherwise it would have countless,
and in my opinion redundant get methods.

The class in question is one which gets customer details. As the
functionality of the application grows, simply adding another case to
the switch statement does the trick.

public function __get($var)
{
switch($var)
{
case 'foo':
// do stuff to get foo
break;

case 'bar':
// do stuff to get bar
break;

default:
throw new Exception("Cannot get $var");
break;
}
}

So there's no confusion or ambiguity, and a lot of flexibility without
loss of clarity.

>Then $foo['sdf'] becomes $foo->sdf. Much nicer to use. You can also
create new data objects on the fly using new stdClass.

I don't like this, personally, but won't argue that much with it.

I agree, it's just a matter of taste. I prefer fewer brackets and quotes.

[Hugh Oxford]

Jesse Burns wrote:

I've also heard (and believe) that the likelihood of throwing away the first
draft and having to start again as you learn what works and what doesn't
work in large projects like this, is a big likelihood. And that's fine with
me as long as I'm learning in the process.

It's funny you should say that - I'm in the process of rewriting an
enormous system which has been successful, will end up looking exactly
the same as the old one and will do the same thing.

It had become unmanageable. I was using an a fairly monolithic system
which worked up to a point, but for the project to go forward it needed
ground up rewriting.

My advice is come up with a simple framework into which you can drop new
pages at will. What has worked for me is to have an index.php which uses
the 'section' variable of the URL to both load up an include file at the
top of the script (for the business logic) and another include file for
the presentation logic (html).

The advantages of OO are enormous. Classes and objects don't just offer
encapsulation, they offer flexibility. You can pass objects to one
another as method arguments, act upon them.

Just don't fall into the trap of writing "God" classes which are
infinitely flexible and general, just because you can. I actually have a
ObjectVerb naming convention for all my classes - CreateFoo, DeleteFoo,
UpdateFoo, often as children from abstract class Foo which might be too
much for some but works for a simpleton like me.