Articles Site Operation
Site Operation
Cached Dynamic Modules pt 3 - Page 2
by: Travis Swicegood
|
July 30, 2000
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:
$str_func on line 234 = handle_xxxAlmost all of the information printed while in debugging mode gives the line at which it was generated to help you find it in the code. However useful this may be, it is strongly advised that you don't use this on public portion of the website. Exposing all of the variable names to prying eyes could prove a disaster to your site security.
In 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:
<!-- xxx cannot be processed - # -->xxx is replaced with the name of the custom tag, and # is replaced with the line number which it was returned.
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.
