Question Regarding Multipurpose Pages

[lateknight]

So I'm in the process of working through "Build Your Own Database Driven Website" and I had a quick question. I'm in the middle of Chapter 6, focusing on building the Content Management System. The author mentions that you can combine all the code for the various functions (add author, delete author, add category, etc.) into one multipurpose page rather than split it up as it done in the book. I understand the theory behind linking all of these functions, my question is: Does building a multipurpose page slow down processing time on the server? Does it improve performance to have one page for each function? I haven't yet gotten to object oriented programming, but if I understand correctly, I can turn all of these functions into classes and call them separately, reducing the amount of code needed. Is this correct? Thanks so much for your help!!

Patrick

[Cups]

I started like that too, a page for each action - for about a week.

Its simple to work on, but boy, how many pages you end up with!

So, for years I made monster pages using page controllers like this

//include files here e.g.
include("shared_header.php");

if( $_POST['saveSubmit']){
//monster block of code

}

if( $someothevar is set ..... ) {
// you get the picture

} 

Now while debugging was a nightmare, with a code editor that understands code folding and brace matching, it was quite bearable. I page = 1 mini app at least you knew which file to look at if there was a problem.

Using that system I then slowly started moving more and more code out of the page into include files - sharing a header and footer for example is quite easy.

Then as you suggest - I started to discover OOP, and moved even more logic off the monster pages into testable, re-usable classes.

Then I found out about "layers" and started moving all my "business logic"
into there own files, y'know all the sql stuff basically.

This is when it all started to make sense. Now the bit I never really 'got' was templates for your views. I dont like them - and I think PHP is a good enough template engine.

So I'd say to you, if you can try and encapsulate your sql statements into their own functions first, move them into their own files, their own folders even - out of the public html tree, and include them as and when you need them. Work from there. I wish I had done that first.

Hope that helps you.

[lateknight]

Thanks so much for writing back! Your guidance leads me to believe that I'm on the right path. I think I'll build this CMS the way it describes in the book, one page per function. Then, as a challenge, I'll work on building the single, gigantic multipurpose page. I know the book goes into OOP towards the end, so I think I'll transition to that a little later on. Thanks again!!

[Cups]

Hi,

I didn't respond on these points.

>Does building a multipurpose page slow down processing time on the server?
>Does it improve performance to have one page for each function?

I dont think so. I think code maintainability is far more important at this stage. Do what you find the most logical.

When performance becomes a problem then there are lots of ways of speeding things up, caching, reducing database bottlenecks etc. There are some really good PHP books out now.

[lateknight]

Hi,

I didn't respond on these points.

>Does building a multipurpose page slow down processing time on the server?
>Does it improve performance to have one page for each function?

I dont think so. I think code maintainability is far more important at this stage. Do what you find the most logical.

When performance becomes a problem then there are lots of ways of speeding things up, caching, reducing database bottlenecks etc. There are some really good PHP books out now.

Lots of reading ahead of me, it would seem! Thanks for the help!