Thanks for your reply. My problem is that I have not done "ordinary OO applications." I stopped programming about 20 years ago (yes, I'm an old timer) and only picked up php seriously about 5 years ago. I only started writing OOP seriously about 2 years ago when I wrote a cart web-app. But only the cart is a class, the rest is procedural. Now I want to write a fully OO web app.
The key difference is the fact that every page load creates all of the objects you use, does it's processing, destroys the objects, and returns the generated code, so you don't have those persistent objects that you're used to with normal OO applications.
The cart objects are stored -- serialized -- in MySQL tables. There are about 3.500 cart objects in various stages of use at any one time.
Kalon's process isn't half bad.
Generally when I create the files for my PHP OO applications, each class falls into one of two general categories:
For simpler sites, each display class will represent a single page. If I want to make them skinnable or something, I may break it into something like a content class and a skin class.
The data classes are just like the any data class you'd have in any other OO project.
That sounds like a good idea. I've been reading Tony Marston's Object-Oriented Programming for Heretics where he suggests using a class per database table. Since I'm comfortable with normalizing tables that sounds appealing to me. If he is to be believed, his method has a lot of detractors.
Yesterday I was toying with the idea and I won't be implementing it his way but I will use a class per database table and, as per your suggestion, a class per browser page. The project is rather large but I think I can build it piece by piece which should keep it manageable.