[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-cocoon-dev
Subject: Re: [ANN] www.nouvo.ch runs on Cocoon!
From: Bertrand Delacretaz <bdelacretaz () apache ! org>
Date: 2004-09-28 6:08:52
Message-ID: DF19FBE2-1114-11D9-9BA7-000A95AF004E () apache ! org
[Download RAW message or body]
Le 28 sept. 04, à 07:54, Stefano Mazzocchi a écrit :
> ...Also, the above seems to imply that you are writing your own
> generators? or are you using XSP or what?
Yes, XSP all the way through...just kidding. It's MySQL, OJB, java
code, Flowscript, XSLT, map:aggregate, CInclude and more XSLT, in order
of appearance on stage.
To control the front-end cache I wrote a simple Action to set these
HTTP headers as shown in my previous message, then I just add this to a
pipeline
<map:act type="http-cache-headers">
<map:parameter name="cache-validity-seconds"
value="{nouvoCmsConfig:blahblah}"/>
<map:parameter name="cache-info" value="www.forum"/>
<map:parameter name="page-info"
value="{3}.{4}.m{5}"/>
</map:act>
To define how long to cache the page, and add some logging info to
oversee the whole thing more easily.
Making the front-end cache validity dependent on the content would be
very easy then.
> ...One approach that I recently thought to fix that is 'client-side
> templating': basically you render the page with a bunch of empty <div>
> or <span> tags with a specific ID, then you just link a javascript
> file that gets called with <body onload=""> which calls a method that
> sustributes all those tags with the right content, so the only
> user-specific part of your page is the javascript file that can be
> much faster to generate that the entire page (and can be completely
> stateful)..
Great idea, keep the HTML stateless and generate just the tiny
user-specific bits via javascript - which you can also cache with the
same mechanism I guess.
-Bertrand
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic