Peter Hunsberger wrote:
What you want is user specific data components, not user specific
presentation components. The presentation is the last thing to go out
the pipeline (the final set of assembled data components). Don't
think in terms of HTML, think in terms of XML that can easily be
converted into HTML. The HTML presentation details are in the final
XSLT. The XML data components are what are aggregated (and cached).
Yes. For us Toplink caches business objects (avoiding trips to database),
the presentation tier caches certain long-lived DTOs (avoiding trips to
backend),
and also caches many of the Doms of XML that are produced (avoiding
Java-to-XML generation via JDOM).
However that still is not enough-- the XSLT processing itself--the
transformers that produce the
final content from generated XML--are taking too long. We want to cache
as much of that as we possibly
can. After all, XHTML is just XML, why shouldn't some of it be cached??
That's not to say the final result can't be cached. It can, but it's
cache validity is only as good as the cache validity of that of the
shortest lived data component.
I don't understand.
I thought that each pipeline can be cached.
My mental model is as follows:
Say Pipeline A gets content from Pipeline A1 and A2.
Pretend that three pipelines have several generators, transformers, and
serializers, all of which are theoretically cacheable.
Say A1 is cached for 1 second.
Say A2 is cached for 1 year.
Pipeline A will regenerate its content, and ask A1 and A2 for their content.
A1 will regenerate its content.
A2 will serve up its *cached* content. Why would A2 have to regenerate
itself? It doesn't make sense...
Urg. My mental model must be flawed, unless "data component" does not
include "result of pipeline" :-{
--Craeg
