Thanks Emile for the info. I welcome all info. :-) Curtney
On Tuesday 27 July 2004 12:10 pm, Emile wrote: > Broadvision introduced caching at a page level, which basically meant that > parts of the page could be cached, thus saving time on compilation of > parts/all of the jsp - this would obviously have been an additional caching > level over and above the apache front-end page caching - which wasn't used > much in my experience. I think it was implemented through an event-driven > object model, with the caching object being responsible for re-compilation > of code given an event (whether that be data update or time elapse or > whatever) and storage of the output in a property for quick access by the > page-compilation module. > > .. some useless information :-) > > Regards > Emile > > ----- Original Message ----- > From: "Ernst Bunders" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, July 27, 2004 1:50 AM > Subject: RE: Dynamic generation of static html pages > > > don't forget that an important function of the type of caching you are > looking for is to sheeld the appserver from too many requests. That's why a > frontproxy is such a good idear. Requests on a apache webserver are much > much cheaper than requests on a servlet container (tomcat). As kees > mentioned mmbase is allready caching the nodes needed to populate your > pages. So you dont have to introduce another caching layer on that level. > Just make shure the request never reaches the appserver. > > Ernst > > > -----Oorspronkelijk bericht----- > > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Curtney Jacobs > > Verzonden: vrijdag 23 juli 2004 19:25 > > Aan: [EMAIL PROTECTED] > > Onderwerp: Re: Dynamic generation of static html pages > > > > > > I am thinking that having a class that implements the > > MMBaseObserver interface > > (thus knowing when the object has changed) and is registered > > to the builders > > you want to have statically cached. That way you have the > > benefit of having > > somethings statically generated. For instance, all article > > items could be > > cached but news items could be dynamic (since they are > > updated or changed > > more often). > > > > However, it still leaves me with the problem of how to pass > > the data (article > > content) to the article template (which is composed of mmbase > > taglibs) within > > the Observer class. I am thinking perhaps calling lynx -source > > http://www.sitename.com/article?nodenumber then save the > > output to a file on > > the server. Thus having the entire page look and feel, as > > well as the article > > content save on the server. > > > > Am I making this to complicated? Is there a better way. > > > > _Curtney > > > > On Friday 23 July 2004 02:28 am, Michiel Meeuwissen wrote: > > > Kees Jongenburger <[EMAIL PROTECTED]> wrote: > > > > On Friday 23 July 2004 11:12 am, Ruud Prein wrote: > > > > > The article describes an excelent web caching mechanisme :-) > > > > > > > > Actualy with the new query code and a bit of special > > > > query logging I > > > > > > think it's possible to to define the relation between a > > > > page and nodes > > > > > > used in that page > > > > > > I was actually pondering about using mm:content for these > > > > kind of things. > > > > > Every node on the page could communicate itself to > > > > mm:content and say its > > > > > 'lastmodified' to it. The, mm:content could even send the correct > > > 'Last-Modified' header, but of course it could perhaps also > > > > be used for > > > > > more active mechanism communicating with static-page-caches. > > > > > > Michiel
