Rather than do that, what I'd recommend you do is cache your
retrieved data. That way, you can apply varying rules to 
various types of data and only retrieve the data you know is
need of updating.

In your case, if you invalidate a template, you've already
had to pull half the data at least just to learn than, and
now have to pull all the data and do a full reload of the data,
grab the cached templates and reprocess.

You'd be better off changing your data retrieve stage to
cache one type at a time and always do a full process on the
cached template. 

Once you have a cached data pool, you can add an intermediate
step where you verify that none of the data had changed and
send the cached post-processed document. But your heuristics
for doing so are going to rely on you knowing what has and
hasn't changed since the last build. And writing that part
will take you half way to caching the data anyway.

I've given this a lot of thought recently as I build a project
for work. You can cache local files (templates, cache validity
depends only on filetime, available quick and local), cache
data records (db accesses, cache validity depends on record
update schedule or volitility, available quick but remote, may
require db redesign to add change dates at the table or record
level), cache page output (processed templates; depends on
template cache vailidity, data validity, and potentially
user/login variations; availibility is all over the map).

In order to cache your output pages, you're going to have to
solve your data cache issue. And since the remote call to your
data source is likely a greater issue than the process time,
I'd concentrate on caching it first. Better still you can
concentrate on some easy wins without retooling the entire
system. 

Some of your data probably has a volitility so low you could
just cache it once at the daily logfile restarts.

--mark mills
Xodiax Engineering

> running it through the template.  The problem I have is 
> there's no easy way for an external script that uses the 
> toolkit to know when any given piece of a cached template is 
> out of date.  Sure, I can check the Date Modified of the 
> template, but that doesn't tell me what other files that that 
> template may use for template-fragments/wrappers etc, and if 
> they're up to date.
> 
> What's a good way to find out if all the pieces of the 
> template are up to date?  I don't mind walking through a list 
> of Date Modifieds for each file, but I need a way to get that 
> list without changing TT2 internals, as I'd like to be able 
> to keep using TT2 as an easily upgradeable black box.
-zjej׬����x%��mzjej׬�驕�^��%�+h�m����-zjej׭��d��+����Y���b�ا~��zjej׬


Reply via email to