dave420

Wouldn't parsing an INI or XML file be rather expensive? Wouldn't it be better to at least cache the output into something more immediately useful, say using var_export?

It would probably be quicker to include the MD5'd ID in the database, if you're going to search it via MD5. Otherwise your DB will have to hash and compare each of the IDs as it searches, which is going to be slower than just comparing strings. Why are you hashing the user IDs?

I'd suggest to get XDebug installed on your server and then take a look at where your scripts are taking the longest, and then seeing what can be improved to bring those times down. If you're repeatedly generating (frying) content when serving a static (baked) file would suffice, then it's worth looking in to seeing if you can bake the currently-fried pages in an efficient manner, paying attention to knowing when the cache is stale, and re-generating it. Of course all of this depends highly on the work your site is performing, which is why I'd suggest profiling the performance to see if it's worth caching, and how to go about that sensibly.

No, I'm just emphasising that they can be used together. $panties->unbunch()

You can definitely have a singleton registry class for storing objects/variables for everything to access - that's a good way to have a site-wide configuration, for example.

Thanks for the response! So you fry everything to order? Have you performed benchmarks on this system - do you know how well it would scale? I find I'm getting more and more obsessed with performance and scalability these days

For that example, why not use a singleton database object? Then it's even easier.

Does anyone here feel particularly strongly about either method for generating content? How about a solution that bakes semi-fried pages, allowing templates and objects to be combined in flat PHP files, ready for use? I'd like to hear the thoughts of you guys and gals, if possible. cheers!

Registries can be made into singletons if you want to have a respository available from anywhere, or not, if you want to pass them around.

Yes - don't use the anchor The anchor is not sent to the server - it's used by the client only. If you want to use pagination, I'd suggest using the query string. You can just put the page number in the query string like this: index.html?2 ... index.html?20 (where no query string means page 1).

I'd recommend you store them in the filesystem - that's what it's there for Make your script create the necessary directories as needed, and do it that way.

Well, you can use mod_rewrite for that, though these days it's usually a better idea to do it in code instead.

It's very easy to do this. You can use the open-source LAME utility to check the MP3 and to re-encode it if needed. It's pretty quick, too, and offers great results. Download it here: http://lame.sourceforge.net/download.php. If you're using Windows, get the binaries here: http://lame.bakerweb.biz/

Have you thought about normalising your database?

Create a boolean variable before the loop, and in the while loop NOT it so it flips on every iteration. Use that true/false value to change the content of a variable, say $colour, and then use that in the TR tag to set the background colour (using CSS). Here's a quick example. <?php $rowState=false; while ($row = mysql_fetch_array ($result)) // loop through the rows outputing them as html table rows { $colour=($rowState=!$rowState) ? "#FF0000" : "#00FF00"; // $row["fieldname"] returns the content for the field in the current row echo "<tr style=\"background-color: $colour;\"><td>" . $row["MANNAME"]. "</td>"; echo "<td>" . $row["prodtype"]. "</td>"; echo "<td>" . $row["proddesc"]. "</td>"; echo "<td>" . $row["prodnar"]. "</td>"; echo "<td>QUALUBE " . $row["prodequiv"]. "</td></tr>"; } ?> I'd suggest using CSS classes instead of changing the background-color directly, just for ease of changing it later.