aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
authorGiuseppe Bilotta <giuseppe.bilotta@gmail.com>2011-08-30 23:08:26 +0200
committerGiuseppe Bilotta <giuseppe.bilotta@gmail.com>2011-08-30 23:08:26 +0200
commit37a0eb353ea56d5e53cbe191e86844b17bf4c5ce (patch)
tree4e253abdb15da69e29f5bcecdc0b96d15332836e /doc/bugs
parent2c2c537dd521bbc659f0499af72ca70078d97d50 (diff)
downloadikiwiki-37a0eb353ea56d5e53cbe191e86844b17bf4c5ce.tar
ikiwiki-37a0eb353ea56d5e53cbe191e86844b17bf4c5ce.tar.gz
Reply to smcv about dependency ordering, post-scan hooks and conditionals
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/conditional_preprocess_during_scan.mdwn18
1 files changed, 18 insertions, 0 deletions
diff --git a/doc/bugs/conditional_preprocess_during_scan.mdwn b/doc/bugs/conditional_preprocess_during_scan.mdwn
index baa430e19..254ebac22 100644
--- a/doc/bugs/conditional_preprocess_during_scan.mdwn
+++ b/doc/bugs/conditional_preprocess_during_scan.mdwn
@@ -17,3 +17,21 @@ reprocessed is done so in the same conditions as the original call.
> been scanned yet). If you have a clever idea for how to fix this, I'd love
> to hear it - being able to specify a [[plugins/contrib/trail]] in terms
> of a sorted pagespec would be useful. --[[smcv]]
+
+>> I have a solution to the dependency-ordering problem in a different
+>> branch of my repository, with a post_scan hook mechanism which I use to
+>> be able to sort outer inline pages according to the last modification
+>> date of their nested inline pages. The way I implemented it currently,
+>> though, doesn't use the existing hooks mechanism of ikiwiki (because
+>> it's something which I believe to be more efficiently done the way I
+>> implemented it) so I don't know how likely it is to be included
+>> upstream.
+
+>> For what it's worth, I think that my post_scan hook mechanism would work
+>> rather fine with your trail plugin. However, the case of the if
+>> directive is considerably more complicated, because the conditional
+>> can introduce a much stronger feedback effect in the pre/post scanning
+>> dependency. In fact, it's probably possible to build a couple of pages
+>> with vicious conditional dependency circles that would break/unbreak
+>> depending on which pass we are in. And I believe this is an intrinsic
+>> limitation of the system, which cannot be solved at all.