#native_company# #native_desc#
#native_cta#

Cached Dynamic Modules Page 2

By JP
on July 30, 2000

Now, the final html returned to the user is:

<title>Hello world</title>

<!-- my-style cached output (14:32) --//>

<font face=Arial size=2 color=yellow>

<!-- my-style end of output --//>

Hello world

You can endlessly expand on this model, adding modules is easy, as each module only
has to conform to the calling convention my_modulename ($options) and return some
html that can be replaced instead of the original call in the .my file.
Now, why would you do this? There are three important reasons:
  • caching
  • security
  • consistency

Caching

The parser optionally stores the output from the module in its cache directory. The
next time someone calls <my-style name=test>, the parser checks
if it can use the cached entry by checking on the expiration time of this particular
entry. There is a default for all entries, but you can set it for each tag specifically
by using the cache=x parameter:
<my-style name=test cache=3600>
Now if there is a cached entry, it will only be used if it is not older than one hour.
After this hour, the module will be called again and the newly returned html will update
the cache entry.
You will not want to use the cache for all tags, but for e.g. database driven modules
or modules that use external webserver to retrieve information are likely to have a big
performance penalty, so the caching might prove a big speedup here. Let alone when the
underlying database or webserver is down, YOU then have a cached entry to serve!