From 5e1b3c0c363f4da91413b11905cce3a6d9af7abd Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 22 Apr 2009 16:00:36 -0400 Subject: [PATCH] plan of attack --- ...-compilation_inclusion_of_the_sidebar.mdwn | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn index 7586c060b..568b75747 100644 --- a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn +++ b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn @@ -28,3 +28,23 @@ NicolasLimare > sidebar could be done as you describe using .shtml. --[[Joey]] [[wishlist]] + +> I have a plan for a way to avoid unecessary rebuilds caused by the +> sidebar. The idea is to use wikistate to store what a sidebar renders to. +> Then in the needsbuild hook, render sidebar(s) and compare with their +> previous stored rendering. If a sidebar's rendered content has changed, +> then all pages that display that sidebar need to be forced to be rebuilt. +> +> Also, if there is no previous stored rendering for a sidebar, or +> if there is a stored rendering for a sidebar page that no longer exists, then +> the pages need to be rebuilt. (This should deal with the [[bugs/Building_a_sidebar_does_not_regenerate_the_subpages]] bug. +> +> This would also save significant time, since the stored sidebar rendering +> could just be dumped into the page by the pagetemplate hook. Current code +> re-loads and renders the same sidebar file for every page built! +> +> The sticky part is relative links on the sidebar. These would need to +> be modified somehow depending on the page that the sidebar is placed on. +> Doing that seems hard/tricky. Maybe it would not be worth the optimisation +> of using the stored rendering after all, and instead still re-render it for +> each page? --[[Joey]]