![]() Join Up! 96816 members and counting! |
|
|||
Cached Dynamic Modules - The 3rd Incarnation
Travis Swicegood
For those of you who have been interested in the evolution of the Cached Dynamic Modules, here's the
3rd Incarnation. This article is written on the assumption that you are partly familiar with the
Cached Dynamic Modules script. These first few pages go over the additions, and updates to the
original code; then dives right into the (pretty)
source code.
The code should look familiar because a lot of the code used in this version has been used verbatim
to the way Spencer
set it forth in his article, Another Look At "Building
Your Website With Cached Dynamic Modules". Thanks are due to both
Spencer and
JP for
their initial work on the project.
Change
Features Added
Debugging of the parser is now available. Nearly all variables are printed in the parse_it() function as they are set. A common output would read: In Spencer's version, no checking was done to ensure that the module file to be included existed. Checking was added, and if the file does not exist, the current information is returned with the following error message added to the line above the custom code: Before, only opening tags (tags without a '/') were processed. This would be fine as long as the custom tags were not being replaced by tags that went around the text or images within the opening and closing tags (ie. a table cell). Support was added, in an identical way to the opening tag, except it calls handle_close_xxx() instead of handle_xxx(). The module file is still the same. In previous versions, all other HTML/text located on the same line as your custom code was discarded. Now any text before and/or after the tag is returned with no changes. Custom tags were limited to the <my-xxx> format before this version, now the my is replaced with the extension of the file that is parsed (ie. If you wanted to use <my-xxx> the file must have the extension .my) A new attribute has been added, CACHE. The values of CACHE are: read - force a read of the cache file; write - force a write to cache; no - force that the cache neither be read nor written to. Obviously, problems existed within this program if everything was cache. For instance, if a section of a website that dealt with sensitive personal information (credit cards, SS#, etc) cached the information that it was processing, the potential for hackers to gain easy access to this information was huge. I do believe that this version will be safer for use in an eCommerce setting. The default cache time is now set via the call to the parse_it() function. This is set so you can change how long the default caches are set for programmatically. This will require editing the parse() function, however. Modifications
In several areas there were repetitive if() statements, and several if() statements that were better used as elseif(). Also, several of the while() statements were changed to for() statements, as well as several for() statements had some repetitive function calls that weren't necessary. All in all, the changes were minor, but in a shared server environment, could cause extreme havoc on the system performance. The parse() and parse_it() functions were changed to the following: The comments within the file parse.php3 have been extensively revised. So much so, that documentation outside the file would be extremely redundant. Also added in the comments section at the bottom of the file are instructions on how to setup parse.php3 to run, as well as example files to test the parser out. To avoid any potential problems with the parse() and parse_it() functions not being default, the initial call to parse() has been moved to the end of the file, but before the setup instructions. |