Forum Moderators: coopster
I'm considering a new project build strategy via modularizing certain areas of - typically reusable - code.
These pre-built modules would be "included" / "required" as programatically needed.
From the standpoint of code re-usability, maintenance and build efficiency, this certainly seems like a good idea in theory. But, like anything in life, I suppose a good idea like this could be taken to insensible extremes.
For example, I was thinking of putting EACH OF THE FOLLOWING into separate php files: doctype, metatags, css link sources and javascript link sources; each would then be "required_once" at the very top of my pages.
My motive - and the above is just one example that I'm noodling over - is for an extreme level of organization, but I'm also wondering if this scheme may be:
1. bordering on the ridiculous, and/or
2. impact the loading speed of my projects?
I remember reading somewhere that using "too many" includes/requires would degrade loading performance due to an over abundance of server calls.
So, do other folks here do this kind of thing? Is it a good idea? Or is it only a good idea in "moderation". If moderation is the key, then how moderate should one be?
All input greatly appreciated!
Neophyte
There's obviously performance implications--there's no way around that; the simple overhead of opening that many files will slow you down by several tenths of a second--but with many of the systems I've worked with, it's the only way for the programmer to keep his sanity intact.
I've found that it's best to take a moderate approach. Simply ask yourself "is this information all of a similar sort?" If it is, by all means put it all in the same file. You probably shouldn't have three separate files for the information that goes between your <head> and </head> tags.
However, it is definitely advisable to do things like separating your PHP code from your HTML. This alone makes your code MUCH easier to read and cleaner.
My typical index.php request lifecycle goes as follows:
index.php (contains PHP necessary to produce the output specifically for the index page)
templates/page_start.php (contains PHP initialization code run by every page--such as initializing classes and required variables, dealing with user logins and/or groups etc.)
* (include PHP class files, function files, and files with specific information and functions for the actions the page needs to perform--generally no less than 5 pages and no greater than 30, though very complex systems can go higher)
templates/page_template.php (inserts information from all resources into a single giant HTML template--absolutely no logic is performed here; anyone with general knowledge of CSS and and HTML can edit this page--in fact this page is often created by someone with no scripting knowledge whatsoever).
I think you're going overboard a little by using completely separate files for such related information as the contents of the <head> </head> tags and DOCTYPE. There IS a bit of performance overhead for every file you include, and there's not much difference at all between having a generic header include that produces your entire header and producing each piece of it individually. Especially if you're using dynamic content, such as changing CSS links on the fly, why not just generate the CSS links in PHP, then in your header file just do something like...
<!DOCTYPE...>
<head>
<title>PHP Header Example: <?php echo $PageTitle;?></title>
<?php echo $CssLinks;?>
<?php echo $ScriptLinks;?>
</head>
If your server supports it, you could go so far as to reduce the above code to the following:
<!DOCTYPE...>
<head>
<title>PHP Header Example: <?= $PageTitle?></title>
<?= $CssLinks?>
<?= $ScriptLinks?>
</head>
As I said before, I like to have everything that produces output in one giant page template. I'm what you might call "color challenged", so I need designers to be able to help me out. However, as a general rule, I have to assume they can't read PHP code, and won't understand how or why their page is chopped up into tiny pieces in many different files.
Too many files can actually decrease your code's readability as well--it's quite distracting and annoying to have to try and find a function that's being called in file A, but actually resides in file M, with files C, Y, J, H, O, P, R, and Q being laid out in a nice breadcrumb trail of includes stringing all the way back to A.
So, in summary...
Yes, use includes to separate your code logically. However, reduce the number of includes whenever possible. Group related code together--for instance, all your data access code can probably go in one, maybe two files--and try to keep entire HTML pages together if possible. Obviously, this won't work in every situation, but these guidelines, I've found, make your code relatively lightweight and easy to debug.
Edited for ease of reading.
[edited by: WesleyC at 7:42 pm (utc) on July 20, 2007]
if your actual dynamic content only changes once a day, for example, say, at midnight, then you only really have to assemble it then.
if you cache the final result and save it somewhere on your server then you can just deliver that every time a user comes calling.
you can also find some pretty smart caching engines which are clever enough to cache bits of the page that are still the same and only reassemble the parts that have changed.
