Using PHP to produce PHP really screws with the head.

[KLB]

So I've come up with the ultimate way to totally screw with one's head. In order to reduce database calls, I'm developing a PHP script that produces a PHP script that dynamically creates an HTML menu.

Okay are you confused? Follow along:

PHP script #1 makes a database call to a really large database table to generate PHP script #2. PHP script #1 will get run only after I update my database. It will print out to a text file PHP script #2, which I will then copy and paste into the project it will be used in.

PHP scipt #2 will not make any database calls, but will sleuth out which "page" the user is on and disable that menu item when it generates the HTML menu.

This will give me my "slick" page sensitive menu I want, but won't tax my database only to produce a menu every time a user hits my website.

The really hard thing about this is making sure to put the correct escape sequences in my code. For instance:


if($cur==250){
echo "
echo \"<ul class=\\\"HMTMenu\\\"><li>\";
if(\$bn!=\"\" || \$bu!=\"\"){echo \"<a href=\\\"/yogi/hazmat/table/\\\">
";
}
It will be really entertaining to see how long it takes me to debug this mess.:p

[AndyH]

$script = <<< EOF

<PHP code goes here>

EOF;


Would that work?

[Chris]

http://www.websitepublisher.net/article/html-cache-php-database/

Check out that. I do a mostly similar thing and that is now I do it.

[KLB]

Doesn't that just figure, the hardest most mind warping coding idea I can come up with works after two extremely minor tweaks yet the easy stuff can spit out all kinds of errors. Literally the the biggest error I found was with me forgetting to include a start position in my usage of the "substr() function. I did 'substr($str,9)' instead of 'substr($str,0,9)'.

The code actually turned out to be reasonably compact. Basically it was a while loop that ran through 3,500 records creating links for 250 record pages where a max of 12 characters of the "proper shipping name" of the first chemical on a page and a max of 12 characters of the "proper shipping name" of the last chemical on a page were in the the link anchor text. The first PHP script generated a series of if() statements that the second PHP script will use to determine whether or not to make each link live or not.

By the way I hate using <<< EOF/EOF; instructions because I always lose what is going on in them and in this case the generated code segments weren't long enough to justify it (one or two lines each).

- edit --
Oh I'm kind of lazy so instead of writing the code to a text file. I dump it out to a web browser inside of an HTML comment tag <!-- --> and simply copy the generated PHP code from the HTML source. I then paste it into the section of the master PHP file that needs it. To turn on or off the link generation code I simply throw a switch into the top of the file. When I need to generate new menu code I turn the switch on, load the page, copy the code from the source and then turn the switch back off.

[rpanella]

The easiest way I would think to do this would be to either have script #1 simply print out a text file with each page name and url on a line and have script #2 read that it, or to have script #1 output a very simple php file which just creates an array like this:


$links['page1.html'] = "Blue Widgets";
$links['page2.html'] = "Green Widgets";

Then script #2 could include this php file and use the array to create the menu. This would keep all the HTML code in script #2 and make it much easier to change it in the future.
________
Yamaha Shs-10 History (http://www.yamaha-tech.com/wiki/Yamaha_SHS-10)

[AndyH]

I don't really understand the problem or what you are trying to do but there must be an easier way...

[KLB]

Okay for those that don't understand, I can't be having my database table called for every request to generate two of my menus. I do, however, need to generate my menus from the database table after I've done an update to the table in question, which happens like once a year.

My solution is to create a PHP script that I can manually run after a data update. I then manually copy the generated PHP code into the target script that is used to generate the actual pages.

I use a similar method elsewhere on my site to generate menus that don't need updating very often. Figure it this way, this method will save me two database calls per page view of the new section I'm developing.

Chris's method does have the advantage of not needing to manually copy the code in question into my target scripts and to instead simply write the code to a file, which can be called as an include. I might use this method to save a step.

By the way, I'm basically finished creating this piece of code and am now doing the CSS work that formats the menu. I expect to have this new section of my site up in the next day or two. Once it is done I'll be able to demonstrate things a little more.

[Chris]

Yup, an include isn't a big deal.

I actually do two things on my lit site.

1. Write all author & book indexes as static HTML.

2. Write a sidebar file (left menu) for all of the same that can be included on search result or other pages I do not cache.

[KLB]

Okay my new section is online at http://environmentalchemistry.com/yogi/hazmat/table/ the "list by" menu is the part that is generated by a two step process.

For step one I change a hard coded variable at the top of the PHP file that switches the page from normal "hazmat table" mode into menu generation mode. This is done off line as the database on my computer is the same as the database on my web server. Once I've turned on the menu generation mode I simply load the off line version of the page once, then turn the menu generation mode off. The generated include file for the menu is then uploaded to my server.

When the HazMat table script is in normal mode it uses the include file that was generated in step to generate the "list by" menus (directly below the page title in the middle column).

The beauty of this two step process is that it allows me to eliminate four database calls that would normally be needed to generate the "list by" menu and page title if it weren't for the two step process.

The "list by" menu is a set of drop downs that rely on the "hover" pseudo class that has a JavaScript override which is only used by IE 5.5 and IE 6.0 as they do not support the pseudo class correctly.

Now nobody but another W3C validation fanatic would appreciate this, but like other parts of my site, this new section validates to both HTML 4.01 Strict and CSS2 specifications (no errors and no warnings).