Nexista Blog

Just finished up a bunch of work on the caching extension, which required some reworking of init.php and foundry.php.

I’m trying to keep the caching extension as simple as possible. It will do a few clearly defined tasks:
* save the output buffer
* check the output buffer
* return 304 if saved buffer hasn’t been modified since the client last downloaded it
* return the output buffer

It will also send headers specified in sitemap gate attributes. The sitemap structure is getting a little wacky, but it works! For example, let’s examine this gate:

    <map:gate name="dynamic-css"
      cache="600"
      nosession="true"
      content_type="text/css"
      cache_control="public, max-age=600, must-revalidate"
      >
        <map:action type="header" params="Content-type,text/css"/>
        <map:action type="header" params="Cache-Control,public; max-age=300; must-revalidate"/>
        <map:xsl src="templates/css/dynamic.css.xsl"/>
    </map:gate>

Why repeat content type and cache control? I can’t think of another way at the moment, and its not a big deal. Perhaps init should natively handle headers. For now, I think its *OK*, but if there is substantial need for expansion, we’ll re-factor.

Explanation:
The gate name is basically the url, the cache is the number of seconds the cached file will be good for, nosession causes init to omit any session_start calls, content-type is to make sure the header is sent, even when a cached file is output instead of the gate getting processed (which should perhaps simple be sent by init), and the same with cache_control.

I’ll have to think about that. Using gate attributes to specify http headers for init to send. Maybe not…. I don’t want to muck up init with too many non-essentials. In a way that already has happened due to the info array which is built in the compiled sitemap… hmmm.