This is a much better idea, and, no, I don't have to use a null
stylesheet, 'ell, I don't even need the "axkit:" URI (vindicating the
advice I've heard on this list "there are very few things that require an
axkit: URI") -- I was using these to _force_ superfluous style processing
just to get the data in the cache. In my experiments, a relative URI in an
(LibXSLT at least, it's all I've tried) XSLT document() function calls the
handler directly; perfect fit for your technique. Thanks -- it seems to
work great.
On another note, kudos to the AxKit developers for making the caching so
simple to use. I guess I went into it lazily figuring it would be harder.
One question:
> # reset cache file's status in case get_fh is
> # called again, so it gets reevaluated:
> $self->source_cache->{mtime} =
> $self->source_cache->{exists} = undef;
Am I missing something, or is this necessary? I'd rather get recently
(i.e., since the first time content was delivered by this request) stale
cache data than inconsistent cache data within the context of the same
request.
Finally, has anyone thought about the possibilities of hash collisions in
the cache? I was thinking about extending the cache to include an encoded
key in the filename, just to prevent collisions (my application delivers
financial information to numerous customers and it'd really turn some of
them off if they received someone else's data; it worries me even if
the likelihood is astronomically small). Looks like a simple enough
thing to do in a subclass.
-jtm
On Tue, 14 Oct 2003, Jason Johnston wrote:
> Hello Jason--
>
> If I understand you correctly, you're trying to do something very
> similar to what I've done in a custom provider of my own.
>
> Basically, you can use AxKit's Cache module directly from within your
> Provider, instead of just letting it go and hoping AxKit caches it later
> on. My approach makes the Provider *always* return an XML source cache
> file from get_fh, with some extra logic to generate the cache file first
> if it doesn't exist or is out of date.
>
> package MyProvider;
> ...
>
> sub get_fh {
> my $self = shift;
> my $r = $self->apache_request;
>
> # If the source data is not cached, or is cached but
> # out of date, reevaluate it and write it to the cache:
> if(!$self->source_cache->exists ||
> $self->has_changed( $self->source_cache->mtime ))
> {
> # Do all your database query and XML generation here...
> my $xml = ...;
>
> # Write it to the cache:
> $self->source_cache->write($xml);
>
> # reset cache file's status in case get_fh is
> # called again, so it gets reevaluated:
> $self->source_cache->{mtime} =
> $self->source_cache->{exists} = undef;
> }
>
> # Return filehandle of cache file:
> return $self->source_cache->get_fh;
> }
>
> sub get_strref {
> # Get the strref from get_fh and return it...
> }
>
> sub source_cache {
> my $self = shift;
> return $self->{source_cache} if defined $self->{source_cache};
>
> # Create an AxKit Cache object to store the source data:
> return (
> $self->{source_cache} = Apache::AxKit::Cache->new(
> $self->apache_request, $self->key, '_source_data'
> )
> );
> }
>
> This takes care of caching the XML source, completely separate from the
> normal output caching.
>
> You may still have to run the result through an identity transform (or
> as you suggested a null Language processor, which would be faster), but
> at least your caching will no longer depend on completion of the entire
> pipeline and AxKit::deliver_to_browser. So you'll be able to use axkit:
> URIs and still get the source caching since it all happens within the
> Provider.
>
> I haven't run into any problems using this approach; hopefully it will
> work for you as well.
>
> Best of luck.
> --Jason
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
