AKA Panama Jack wrote:Hockey wrote:When you develop an web application which technique do you prefer or use?
I personally use a single monolithic index.php with page state variables
I find everything much cleaner this way...
Previous to that approach I used a template engine, but used seperate scripts for every page, etc...
Which do you prefer?
Interesting how most people posting went off on tangents without really answering your question.
First question they should have asked is...
"Are you using a CMS backend that controls all of the menus, selections and content?"
If you are using a CMS backend then you will probably be using a single index.php program to build each page based upon the get/post values. This usually results in a much SMALLER index.php for controlling everything instead of a massive index.php or many smaller php files for each page.
If you are NOT using a CMS backend then using a monolithic index.php is going to be detrimental in the long run. It really is considerably harder to debug, expand and track down issues that may arise. You would be better off sectioning out every page into seperate page files. This will make it considerably easier to maintain and upgrade. If you had a problem with one page you can disable it EASILY without affecting the entire site which is what usually happens with a monolithic index.php.
This site
http://www.aatraders.com/ doesn't use a CMS backend. The index.php controls 4 different pages and quite frankly is a pain in the butt to update and maintain. Fortunately all of the other pages are individual php files that are about 2-3k in size. Every page uses the Template Lite templating engine which makes the program code for each page tight and concise. If I were to make one large index.php it would be over 200k and a complete and total NIGHTMARE to maintain.
I would always stay away from monolithic index.php files as they will cause more harm than good. Plus they take up alot of server resources for no good reason loading and compiling all that unused code. You should only load what is needed for that page and nothing else.
BTW, as a side note...
Search engines tend to spider seperate pages with different names while ignoring pages that have the same name referenced through many get/post variables.
If you had a web site with 100 pages but they all started as index.php
and another web site with 100 pages and they all were different IE: index.php, showthis.php, newstuff.php, ... , mythings.php
you will find that search spiders will follow and save the data from the 100 pages with different names more often than the 100 pages that had the same index.php page. The spiders tend to stop following and saving data if every page has the same page name after a few pages. Having different get/post variables is usually ignored since they focus mainly on the base url. This is why you see mods for phpBB2 that turn forum topic URLs into plaintext.html links. It causes the spiders to actually follow and save the forum content.
Interesting how most people posting went off on tangents without really answering your question
That always happens...I ask a question and expect a pragmatic answer, but get some theory instead
It's long been known to me I am horrible at asking questions I want answers too...
But yes, thank you for seeing it my way
If you are using a CMS backend then you will probably be using a single index.php program to build each page based upon the get/post values. This usually results in a much SMALLER index.php for controlling everything instead of a massive index.php or many smaller php files for each page.
I have a designed a CMS, which uses as single application entry point
index.php for the backend, but generates physical web pages, which are powered by a template engine.
So in a sense, my CMS also doubles as a RAD tool if you were interested in building a web site or application using seperate scripts as opposed to single entry
index.php type programs...
I would always stay away from monolithic index.php files as they will cause more harm than good. Plus they take up alot of server resources for no good reason loading and compiling all that unused code. You should only load what is needed for that page and nothing else
I agree, however, for my CMS application a single index.php is not that difficult to maintain...I personally find that, it's easier to work with than 10 or so seperate scripts, although I have used separate scripts in the past due to parsing and execution times being an issue with a massive
index.php
I really like the idea of being able to authenicate a user in one single place as opposed to having to call it in every script which needs it...
Especially in during initial development, because I always change my API like crazy...
Perhaps now I could consider using separate scripts, but initially IMHO it was a good idea to use a monolithic
index.php
Search engines tend to spider seperate pages with different names while ignoring pages that have the same name referenced through many get/post variables.
I think it has more to do with the fact it's a dynamic URL than it does a web page having the same name.
I believe Google stills suggests static URL's although they do spider some dynamic pages, it does stop after a while.
Cheers and thanks for the input
