Alexander Klimetschek skrev:
I just wrote a pipeline that fixes my other problem [1] (by selecting
between two different pipelines based on the actual running mode) and
included this fix for the caching key which works fine. I have to pass
through each of the ProcessingPipeline methods anyway and in each call
that has the Environment as parameter I change the uri prefix set in it:
private void fixEnvironmentForCachingPrefix(Environment env) {
if (this.fixMissingCachingPrefixWithBlockServlets &&
(env.getURIPrefix() == null || env.getURIPrefix().equals(""))) {
ServletContext context =
BlockCallStack.getCurrentBlockContext();
if (context instanceof BlockContext) {
// use the mount path of the block as the prefix
String mountPath =
((BlockContext) context).getMountPath() + "/";
env.setURI(mountPath, env.getURI());
}
}
}
The trick is using the static method
BlockCallStack.getCurrentBlockContext() and using the mount path as a
unique and short URI prefix, which is then used by the caching pipeline
implemenations. You are free to consider it as a dirty hack ;-)
I guess that it currently is hard to solve the problem without hacks.
I plan to create a special Spring "call scope" (Spring 2.0 allows for
custom scopes). The call scope will embed the block call stack (and
maybe also the sitemap call stack) in a way that make it possible to use
dependency injection rather than static methods for getting dynamic info
like the current call context.
/Daniel
