Cached Dynamic Modules pt 3 Page 2

Features Added

Debugging mode

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_xxx

Almost 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.

Module file checking

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.

Closing tag support

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.

Other HTML on the same line

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.

Dynamically generated tag intro

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)

CACHE attribute

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.

Default cache time update

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.