Ross Gardler wrote:
> [OT - but related] This is perfect for the Google Sitemap plugin that
> has recently been contributed to the whiteboard. Are there any docs on this?
No. Haven't gotten around to test this a bit more so there is really
not much to document. Feel free to ask if you have any questions.
>> I don't understand how serverside include would solve any problem
>> other than inserting date-stamps?
> Without SSI all navigation, tabs, and other page decoration is a part of
> the served page. So a change to the skin/view results in every page
> having to be regeneerated (yes you could do cleaver stuf with caching,
> but you will still have to do the final stage of processing for *every*
> page).
> Using SSI the page decorations are not a part of the served page as
> generated by Forrest, instead they are separate files that are pointed
> to by the generated page. So, for example, a change in the navigation
> structure only requries a single file to be regenerated - the navigation
> structure.
> How do we know what to regenerate? Use the checksums you describe above
> to create a list of pages to regenerate.
Hmmm. Thanks for explaining that.
Though now that I understand it I think even more that this is
re-inventing the wheel.
Let me explain:
By using ssi to create decorations like menus and tabs you are
basically doing what a dynamic Forrest would do in assembling a page
on the fly (true, the actual mechanism of resolving a ssi is
different from a transformation). The only real difference being that
Forrest/Coocoon alread has mechanisms to determine which parts of the
page are unchanged while for ssi we'd have to create them (Although
some smart systems might actually cache the ssi-content and as a
result be as good as Cocoon.
By using Cocoon's pipeline and an active server we can already tap into
a highly refineded system and achieve the same of better results.
By making the Cocoon cache persistent between session we could even
have this for a static page.
No?
--
Ferdinand
--
Ferdinand Soethe
