forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: smart update
Date Fri, 19 Nov 2004 15:04:21 GMT
Dave Brondsema wrote:
> Diwaker Gupta wrote:
>> Hey everyone,
>> Things are looking great with Forrest, and I'm really looking forward
>> to the upcoming features. There's just one thing that personally
>> really irks me and I'd like to see that happening in the future too,
>> so I'm just testing grounds if I'm the only one with this issue.
>> When I do a forrest site, it takes about 1 minute to render my
>> complete website, which is absolutely fine for complete deploys since
>> we don't expect them to be frequent. However, when I'm working on a
>> new page/article, I often make small small changes and want see how
>> things look like. Clearly forrest site is way too much overhead for
>> this kind of thing. Now of course, you can do a forrest run and given
>> in the URL you want to check, but wouldn't it be great if forrest
>> could be smart about rendering and only work on *modified* pages?
> Forrest cannot really know what the sources of files are.  I mean, often 
> files are generated from a static xml file, but because we use Cocoon, 
> people could have custom sitemaps which generate pages from a database, 
> or people could use the RSS feeder plugin.  How could forrest know about 
>  which files need to be re-rendered?


We could implement a partial solution. Look for common source files 
(*.xml), if they exist, and are newer then add the link to the 
linkmap.html file. Any link for which we do not find a source file in 
the project document space we would assume it is dirty and therefore 
regenerate anyway.

In most projects this would work for the vast majority of pages.

> That said, I think this could be implemented at the Cocoon level with 
> caching.  Cocoon knows about it's own pipelines so it could know whether 
> the generators used in a pipeline are dynamic or not.  I can't remember 
> for sure, but I think this caching is used when for 'forrest run', but 
> not for seperate runs of 'forrest site'.  We'd have to investigate to 
> see if a cache could be re-used.

This is a better solution, but I have no idea how to implement that one.


View raw message