summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorhttp://kerravonsen.dreamwidth.org/ <http://kerravonsen.dreamwidth.org/@web>2010-11-15 23:00:48 +0000
committerJoey Hess <joey@kitenet.net>2010-11-15 23:00:48 +0000
commiteb13521f5276cdd21a3f5990b1a1a17234e40174 (patch)
tree148ba82152ca4c3315e468e0ad9167c575ee82b2
parentf6312319a49cc1860eebbafd937a0f75d8e7baeb (diff)
modular, not replacement
-rw-r--r--doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn2
1 files changed, 2 insertions, 0 deletions
diff --git a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
index 8650e4f2a..9725b6541 100644
--- a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
+++ b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
@@ -61,3 +61,5 @@ HTML::Template's HTML-like markup prevents me from editing templates in KompoZer
I agree that being able to replace the template toolkit would be a great piece of modularity, and one I would use. If I could use the slot-based filling and the conditional logic from Template::Toolkit, we could build much more flexible inline and archivepage templates that would look different depending on where in the wiki we use them. Some of this can currently be accomplished with separate templates for each use case and a manual call to the right template in the !inline directive, but this is limited, cumbersome, and makes it difficult to reuse bits of formatting by trapping all of that information in multiple template files. -Ian
+
+> I don't wish HTML::Template to be *replaced* by Template::Toolkit - as others have said above, it's overkill for my needs. However, I also agree that HTML::Template has its own problems too. The idea of making the template system modular, with a choice of which backend to use - I really like that idea. It would enable me to use some other template system I like better, such as Text::Template or Text::NeatTemplate. But I think it would be a lot of work to implement, though perhaps no more work than making the revision-control backend modular, I guess. One would need to write an IkiWiki template interface that didn't care what the backend was, and yet is somehow still flexible enough to take advantage of special features of different backends. There are an *awful lot* of things that use templates - not just the `pagetemplate` and `template` plugins, but a number of others which have specialized templates of their own. -- [[KathrynAndersen]]