Welcome to the remotest ends of the Internet! How you got lost enough to find this page is beyond my ability to comprehend, but now that you're here, make yourself at home and look around.
Matthew and Jonathan both have their own web areas. You can have a look at my (not so personal) diary.
Stuff on this page:
I switched to using the KDE web browser, Konqueror, and generally liked it. But it had a problem with this page and others like it which may be fixed by now. One of the <pre> sections below used to have a set of lines which were very long. Konqueror sets the whole page to be the same width as that paragraph which really screws up your view. I've worked around the problem by mangling the example in teh <pre> section, but I've never gone back to Konqueror.
After posting to the Konqueror bug page about this, I got a somewhat rude response that it is a known bug. Known for apparently a long time. FWIW, if you use Mozilla, the problem doesn't show up, so I'm not sure where it originates. On the other hand, Mozilla does paint the background black outside the visible window so you can't read the text that goes too far. Sigh.
If you are using Netscape 4.x, it, too, has a some problems with this page, but most are minor. I'm still trying to figure out why it has decided to start flowing text in my <pre> sections!
Here are some links to jump start you:
Some time ago, I had opportunity to do a lot of PHP work that involved using templates to set up pages. I quickly fell in love with class.FastTemplate and almost as quickly fell out of love with it. The main issue for my use what the use of "dynamic templates." In FastTemplate speak, a dynamic template is a block which is embedded in a template file and which may be repeated multiple times in the output. The problem for me was that I had a need to nest these dynamic template and that was not allowed.
Now this was hardly fatal. In fact, I finished my contract without the feature. But it annoyed me because it required keeping multiple files around for little snippets of HTML which was messy (okay, may I'm just a bit anal on this). So I overhauled class.FastTemplate (version 1.1.0). In the process, I seem to have picked up a noticeable performance because of my extensive use of references and a rather different internal data structure. It's been a while since I tried to benchmark the performance difference and I have made internal changes since then. Plus, being somewhat cynical about benchmarks, I'll save you the nonsense and not quote any numbers. I may not even be faster anymore.
Your old templates should work just fine. If they don't, please let me know. Comptability was one of the goals; to have a real drop-in replacement for class.FastTemplate. I like the nested template structure, but I didn't want to have to go back and change all my templates. Grab a copy and try it out. Let me know what you think. I called it "rFastTemplate" for "recursive" but it's not really any different in functionality than the original. It's hard to come of with a name as catchy as FastTemplate and stealing the original name didn't seem quite right (not to mention the potential for confusion.
Oh, there is one thing you will have to change in your PHP code that uses the new class: the name. You will need to change
require "class.FastTemplate.php3"; ... $t = new FastTemplate ($template_directory);
to
require "class.rFastTemplate.php"; ... $t = new rFastTemplate ($template_directory);
Around June 1, 2001, I modified the code to no longer emit the
<!-- BEGIN DYNAMIC BLOCK: foo --> <!-- END DYNAMIC BLOCK: foo -->
HTML comments when it spits out the parsed template. This makes it easier to hide the fact that you are using a template and also reduces the amount of text flowing over the net (in some cases by a lot).
One of the things you will notice in the comments/documentation at the top of the code is a set of "deprecated" function calls. Well, they're not. I just need to update the documentation. I've found it so useful to keep the same set of calls between the this class and class.FastTemplate that I am unlikely to ever remove the old one. I hardly ever use the new one in my templates just due to habit.
The dynamic block markers have been extended to be pretty forgiving of whitespace and to allow trailing comments after the block name. Only the first "word" following the marker counts as the name of the block. Here is an example of a page fragment which includes a table:
<table>
<tr>
<!-- BEGIN DYNAMIC BLOCK: test-block this is an example of
a dynamic block with a trailing comment -->
<td>{F_SOMEFIELD}</td>
<!-- END DYNAMIC BLOCK: test-block -->
</tr>
</table>
Although not shown, the end market can also contain trailing comments.
Dynamic block names must begin with with an alpha character and may be followed by any alphanumeric plus a hyphen or underscore (this is the definition of a "word" in the previous paragraph). Duplicate names are not checked and will cause odd results (where "odd" means I haven't bothered to find out exactly how it will work).
If a dynamic block is missing its corresponding end block, the class will display an error and no page will be output. Unfortunately, the error message is not so helpful as it fails to identify the name of the block for which it is searching. I think this is a side effect of my omitting the begin/end block HTML comments in the output in general. Getting this fixed is on the TODO list....
Below is a fragment from a template I use for a photo-album project I am working on. The PHP code that fills this in substitutes the URL for a thumbnail image into the variable F_IMGSRC and then generates a list of other images and their sizes to fill in the variables F_OTHERIMG and F_OTHERSIZE. The result is a table full of thumbnail images with a set of hyperlinked text size description below it. To see what the result looks like, you can have a peek at some family photos I've put out.
<table border="5" cellpadding="5" cellspacing="2" width="90%">
<colgroup span="4" "width="25%"></colgroup>
<!-- BEGIN DYNAMIC BLOCK: thumbnail-row -->
<tr>
<!-- BEGIN DYNAMIC BLOCK: thumbnail -->
<td align="center">
<img src="{F_IMGSRC}"><br />
<!-- BEGIN DYNAMIC BLOCK: size-list -->
<a href="{F_OTHERIMG}">{F_OTHERSIZE}</a>
<!-- END DYNAMIC BLOCK: size-list -->
</td>
<!-- END DYNAMIC BLOCK: thumbnail -->
</tr>
<!-- END DYNAMIC BLOCK: thumbnail-row -->
</table>
Using class.FastTemplate.php3, the above template would have had to be split into at least two files even when using dynamic templates; most people would have used three files with no dynamic templates.
If you want more examples, I've started some documentation which has more.
If the example photoalbum was not very satisfying because you can't quite get it to work, here is a "kit" which includes the current working version of class.rFastTemplate.php, class.PhotoAlbum.php (which is very much a work in progress) plus several auxiliary files which will almost give you a working photo album.
The kit should be usable as-is with two caveats. First, there is an ".htaccess" file which will override Apache's PHP settings so that the PHP include directory is the current directory (i.e., where you untar the package) and will load the file "prepend.php" from that directory. If your Apache server is not configured to allow you to override options ("AllowOverride Options"), then you will have to put the PHP code someplace where Apache can find it. Alternately, you can move the contents of prepend.php into index.html and use explicit path information to load them. The second caveat is that there are no images included with the sample. But feel free to use the really cute set of images of my kids. But be warned! The tarball is 4.1 MB.
Which brings up the second issue. The file index.html is actually PHP code. If your server requires that PHP code have a suffix of ".php" you will need to rename this file.
I've included some really cute pictures of my second son at age 8-months. Obviously, you are free to replace those with whatever images you like. Just delete the original images and copy your images into the directory where you unpacked this package. Second, delete the contents of the sub-directory named "cache" and either populate it with your rescaled images or change it's permissions to 1777 so the web server can write to it. The script mkimg will try to generate files in the cache directory. Here is what the fully-populated contents of mine look like:
258 roland> ls -l cache/ total 212 -rw-r--r-- 1 apache roland 1467 Jun 12 22:16 20010601-0001.jpg.0080 -rw-r--r-- 1 apache roland 2203 Jun 12 22:18 20010601-0001.jpg.0120 -rw-r--r-- 1 apache roland 3019 Jun 12 22:35 20010601-0001.jpg.0160 -rw-r--r-- 1 apache roland 1693 Jun 12 22:16 20010601-0003.jpg.0080 -rw-r--r-- 1 apache roland 2652 Jun 12 22:18 20010601-0003.jpg.0120 -rw-r--r-- 1 apache roland 3618 Jun 12 22:35 20010601-0003.jpg.0160 -rw-r--r-- 1 apache roland 1800 Jun 12 22:16 20010601-0007.jpg.0080 -rw-r--r-- 1 apache roland 2847 Jun 12 22:18 20010601-0007.jpg.0120 -rw-r--r-- 1 apache roland 3933 Jun 12 22:35 20010601-0007.jpg.0160 -rw-r--r-- 1 apache roland 1545 Jun 12 22:17 20010601-0010.jpg.0080 -rw-r--r-- 1 apache roland 2413 Jun 12 22:19 20010601-0010.jpg.0120 -rw-r--r-- 1 apache roland 3410 Jun 12 22:35 20010601-0010.jpg.0160 -rw-r--r-- 1 apache roland 1614 Jun 12 22:17 20010601-0011.jpg.0080 -rw-r--r-- 1 apache roland 2499 Jun 12 22:19 20010601-0011.jpg.0120 -rw-r--r-- 1 apache roland 3475 Jun 12 22:35 20010601-0011.jpg.0160 -rw-r--r-- 1 apache roland 9010 Jun 12 22:43 20010601-0011.jpg.0320 -rw-r--r-- 1 apache roland 25834 Jun 12 22:47 20010601-0011.jpg.0640 -rw-r--r-- 1 apache roland 2254 Jun 12 22:17 20010601-0013.jpg.0080 -rw-r--r-- 1 apache roland 4019 Jun 12 22:19 20010601-0013.jpg.0120 -rw-r--r-- 1 apache roland 6157 Jun 12 22:36 20010601-0013.jpg.0160 -rw-r--r-- 1 apache roland 60755 Jun 12 22:48 20010601-0013.jpg.0640 -rw-r--r-- 1 apache roland 2335 Jun 12 22:17 20010601-0018.jpg.0080 -rw-r--r-- 1 apache roland 4048 Jun 12 22:19 20010601-0018.jpg.0120 -rw-r--r-- 1 apache roland 5921 Jun 12 22:35 20010601-0018.jpg.0160 -rw-r--r-- 1 apache roland 2030 Jun 12 22:17 20010601-0019.jpg.0080 -rw-r--r-- 1 apache roland 3417 Jun 12 22:19 20010601-0019.jpg.0120 -rw-r--r-- 1 apache roland 5021 Jun 12 22:36 20010601-0019.jpg.0160
The original images where named like 20010601-0001.jpg and came straight out of my digital camera. A JPEG comment was added to give the "title" and "subject" information.
This "kit" is very crude right now. I've basically hacked it together in a hurry to provide something that works. Here are some caveats:
So how exactly do you debug you PHP scripts? I'm not expert on this, but I find it inconvenient trying to debug an interpreted file living in a daemon process. I mean, with a real program, you can attach to it with something like GDB. But with PHP, I find myself resorting back to the old printf school of debugging.
html_vardump() is a slight improvement for dumping out data structures. It is more-or-less the same as PHP's vardump but with two modifications. First, all of the output is run through htmlentities() and addcslashes() so that everything will print in a web page. Second, you can decide whether or not you want html_vardump() to print everything or simply return a string which can be printed wherever you like. Not printing is the default.
Here's a simple example of using html_vardump():
$image = "mypic.jpeg"; $exif = read_exif_data ($image); $vardump = html_vardump ($exif, 0); echo $vardump;
And here is what the output from a real picture looks like: