From c721a9ef872db85b26d430a2098234a4fca6ec51 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 17 Apr 2010 13:41:06 -0400 Subject: my autotag branch --- .../auto-create_tag_pages_according_to_a_template.mdwn | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index def55f3ee..867306f0d 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -269,14 +269,12 @@ wrong direction. >> True. I'll do that. --[[David_Riebenbauer]] -> Seems that `%autofiles` stores plugin names as keys, but never -> really uses them. So it could just as easily be an array. -> -> I'd be happy if the `%del_hash` global were not needed. -> Looks like it could be avoided by moving the checks -> that `add_autofile` does into the autofile handling loop in -> `Render`. (Also, that loop should probably be in its own -> function anyway.) --[[Joey]] +>> I've pushed an autotag branch of my own, which refactors +>> things a bit. It is untested so far though. --[[Joey]] +>> +>> * `verify_src_file` only called from Render.pm +>> * Gets rid of `%del_files`. +>> * Uses `%wikistate`. [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe) [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748) -- cgit v1.2.3 From 9fbef7e1d2c4e8bbaf3eaf89885f18b88edbe429 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 17 Apr 2010 13:42:50 -0400 Subject: reformat --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 867306f0d..ed681ac4d 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -269,12 +269,13 @@ wrong direction. >> True. I'll do that. --[[David_Riebenbauer]] ->> I've pushed an autotag branch of my own, which refactors ->> things a bit. It is untested so far though. --[[Joey]] ->> ->> * `verify_src_file` only called from Render.pm ->> * Gets rid of `%del_files`. ->> * Uses `%wikistate`. +[[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]] +I've pushed an autotag branch of my own, which refactors +things a bit. It is untested so far though. --[[Joey]] + +* `verify_src_file` only called from Render.pm +* Gets rid of `%del_files`. +* Uses `%wikistate`. [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe) [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748) -- cgit v1.2.3 From 63e6c00890a11144f8d035f7052a6229227fce52 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Mon, 19 Apr 2010 02:23:12 +0000 Subject: response to the further thoughts --- doc/todo/Multiple_categorization_namespaces.mdwn | 26 ++++++++++++++++-------- 1 file changed, 17 insertions(+), 9 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index ee3bbd88d..1861d860c 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -56,17 +56,25 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit Aside from the name of the plugin (and thus of the main directive), which could be `tag`, `meta`, `field` or whatever (maybe extending `meta` would be the most sensible choice), the features we want are - 1. allow multiple values per type/attribute/field/whatever (fields currently only allows one) - 2. allow both hidden and visible references (à la tag vs taglink) - 3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too) - 4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones) +1. allow multiple values per type/attribute/field/whatever (fields currently only allows one) + * Agreed about multiple values; I've been considering whether I should add that to `field`. -- K.A. +2. allow both hidden and visible references (a la tag vs taglink) + * Hidden and visible references; that's fair enough too. My approach with `ymlfront` and `getfield` is that the YAML code is hidden, and the display is done with `getfield`, but there's no reason not to use additional approaches. -- K.A. +3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too) + * I'm not sure what you mean here. -- K.A. +4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones) + * Are you saying that these must be typed, or are you saying that they can be user-defined? -- K.A. Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters: - * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined. - * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default - * `linktype` : link type for (hidden and visible) references - * `linkbase` : akin to the tagbase parameter - * `queries` : list of template queries this type/attribute/field/whatever is exposed to +* `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined. + * I still want there to be able to be enough flexibility in the concept to enable plugins such as `yamlfront`, which sets the data using YAML format, rather than using directives. -- K.A. +* `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default +* `linktype` : link type for (hidden and visible) references + * Is this the equivalent to "field name"? -- K.A. +* `linkbase` : akin to the tagbase parameter + * Is this a field-name -> directory mapping? -- K.A. +* `queries` : list of template queries this type/attribute/field/whatever is exposed to + * I'm not sure what you mean here. -- K.A. Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. -- cgit v1.2.3 From 99cdd38dd54047d0e79dbf65d58ba11ee38f2c92 Mon Sep 17 00:00:00 2001 From: "http://oblomov.myopenid.com/" Date: Mon, 19 Apr 2010 08:36:38 +0000 Subject: Respond --- doc/todo/Multiple_categorization_namespaces.mdwn | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index 1861d860c..ae35e8dfe 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -62,19 +62,25 @@ Aside from the name of the plugin (and thus of the main directive), which could * Hidden and visible references; that's fair enough too. My approach with `ymlfront` and `getfield` is that the YAML code is hidden, and the display is done with `getfield`, but there's no reason not to use additional approaches. -- K.A. 3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too) * I'm not sure what you mean here. -- K.A. + * Typical example is tags: they are accessible both as `tags` and as `categories`, although the way they are presented changes a little -- G.B. 4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones) * Are you saying that these must be typed, or are you saying that they can be user-defined? -- K.A. + * I am saying that the user should be able to define (e.g. in the config) some set of types/fields/attributes/whatever, following the specification illustrated below, but also be able to use something like `\[[!meta somefield="somevalue"]]` where `somefield` was never defined before. In this case `somefield` will have some default values for the properties described in the spec below. -- G.B. Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters: * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined. * I still want there to be able to be enough flexibility in the concept to enable plugins such as `yamlfront`, which sets the data using YAML format, rather than using directives. -- K.A. + * The possibility to use a directive does not preclude other ways of defining the field values. IOW, even if the directive `somefield` is defined, the user would still be able to use the syntax `\[[!meta somefield="somevalue"]]`, or any other syntax (such as YAML). -- G.B. * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default * `linktype` : link type for (hidden and visible) references * Is this the equivalent to "field name"? -- K.A. + * This would be such by default, but it could be set to something different. [[Typed links|matching_different_kinds_of_links]] is a very recent ikiwiki feature. -- G.B. * `linkbase` : akin to the tagbase parameter * Is this a field-name -> directory mapping? -- K.A. + * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B. * `queries` : list of template queries this type/attribute/field/whatever is exposed to * I'm not sure what you mean here. -- K.A. + * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B. -Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. +Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. -- cgit v1.2.3 From 1b7c455f4a4214bc9df766be4ec2b12adcf679e1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 19 Apr 2010 16:03:53 -0400 Subject: thinking about changing how templatedir works and allowing wikitemplate files into the srcdir --- doc/todo/auto_rebuild_on_template_change.mdwn | 33 +++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 doc/todo/auto_rebuild_on_template_change.mdwn (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn new file mode 100644 index 000000000..c4ffae178 --- /dev/null +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -0,0 +1,33 @@ +If `page.tmpl` is changed, it would be nice if ikiwiki automatically +noticed, and rebuilt all pages. If `inlinepage.tmpl` is changed, a rebuild +of all pages using it in an inline would be stellar. + +This would allow setting: + + templatedir => "$srcdir/templates", + +.. and then the [[wikitemplates]] are managed like other wiki files; and +like other wiki files, a change to them automatically updates dependent +pages. + +Originally, it made good sense not to have the templatedir inside the wiki. +Those templates can be used to bypass the htmlscrubber, and you don't want +just anyone to edit them. But the same can be said of `style.css` and +`ikiwiki.js`, which *are* in the wiki. We rely on `allowed_attachments` +being set to secure those to prevent users uploading replacements. And we +assume that users who can directly (non-anon) commit *can* edit them, and +that's ok. + +So, perhaps the easiest way to solve this [[wishlist]] would be to +make templatedir *default* to "$srcdir/templates/, and make ikiwiki +register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're +used. Although, having every page declare an explicit dep on `page.tmpl` +is perhaps a bit much; might be better to implement a special case for that +one. Also, having the templates be copied to `destdir` is not desirable. + +The risk is that a site might have `allowed_attachments` set to "templates/*" +or "*.tmpl" something like that. I think such a configuration is the *only* +risk, and it's unlikely enough that a NEWS warning should suffice. + +(This would also help to clear up the tricky disctinction between +wikitemplates and in-wiki templates.) -- cgit v1.2.3 From 09c647c1773d5c8eafacea486082684909e47449 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Tue, 20 Apr 2010 02:31:00 +0000 Subject: response --- doc/todo/auto_rebuild_on_template_change.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn index c4ffae178..2799842ed 100644 --- a/doc/todo/auto_rebuild_on_template_change.mdwn +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -31,3 +31,5 @@ risk, and it's unlikely enough that a NEWS warning should suffice. (This would also help to clear up the tricky disctinction between wikitemplates and in-wiki templates.) + +> But would this require that templates be parseable as wiki pages? Because that would be a nuisance. --[[KathrynAndersen]] -- cgit v1.2.3 From 9f00692a798888b9cc9edb30a961c6418efba39b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 19 Apr 2010 22:37:55 -0400 Subject: response --- doc/todo/auto_rebuild_on_template_change.mdwn | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn index 2799842ed..cde19700c 100644 --- a/doc/todo/auto_rebuild_on_template_change.mdwn +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -25,11 +25,15 @@ used. Although, having every page declare an explicit dep on `page.tmpl` is perhaps a bit much; might be better to implement a special case for that one. Also, having the templates be copied to `destdir` is not desirable. -The risk is that a site might have `allowed_attachments` set to "templates/*" -or "*.tmpl" something like that. I think such a configuration is the *only* -risk, and it's unlikely enough that a NEWS warning should suffice. +The risk is that a site might have `allowed_attachments` set to +`templates/*` or `*.tmpl` something like that. I think such a configuration +is the *only* risk, and it's unlikely enough that a NEWS warning should +suffice. (This would also help to clear up the tricky disctinction between wikitemplates and in-wiki templates.) > But would this require that templates be parseable as wiki pages? Because that would be a nuisance. --[[KathrynAndersen]] + +>> It would be better for them not to be rendered separately at all. +>> --[[Joey]] -- cgit v1.2.3 From 16afa9e8446771fabe45ab45d8a36d09034d0319 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Tue, 20 Apr 2010 02:41:13 +0000 Subject: further clarification --- doc/todo/Multiple_categorization_namespaces.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index ae35e8dfe..190070816 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -79,8 +79,10 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t * `linkbase` : akin to the tagbase parameter * Is this a field-name -> directory mapping? -- K.A. * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B. + * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name. Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A. * `queries` : list of template queries this type/attribute/field/whatever is exposed to * I'm not sure what you mean here. -- K.A. * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B. + * Ah, do you mean that the input value is the same, but the output format is different? Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A. Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. -- cgit v1.2.3 From fda191cbbbfa76114a27a53bfc5b90289f26f72b Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Tue, 20 Apr 2010 02:43:44 +0000 Subject: formatting --- doc/todo/Multiple_categorization_namespaces.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index 190070816..74e5bc812 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -79,10 +79,10 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t * `linkbase` : akin to the tagbase parameter * Is this a field-name -> directory mapping? -- K.A. * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B. - * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name. Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A. + * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name. Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A. * `queries` : list of template queries this type/attribute/field/whatever is exposed to * I'm not sure what you mean here. -- K.A. * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B. - * Ah, do you mean that the input value is the same, but the output format is different? Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A. + * Ah, do you mean that the input value is the same, but the output format is different? Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A. Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. -- cgit v1.2.3 From 529929e732e1c6604d31b68e81898780de06e640 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Tue, 20 Apr 2010 02:45:14 +0000 Subject: non comprend --- doc/todo/auto_rebuild_on_template_change.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn index cde19700c..6a1013f8d 100644 --- a/doc/todo/auto_rebuild_on_template_change.mdwn +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -37,3 +37,5 @@ wikitemplates and in-wiki templates.) >> It would be better for them not to be rendered separately at all. >> --[[Joey]] + +>>> I don't follow you. --[[KathrynAndersen]] -- cgit v1.2.3 From 563428ebd2a75cfabccf1974da0c1cbbe07eb369 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 19 Apr 2010 23:52:16 -0400 Subject: response --- doc/todo/auto_rebuild_on_template_change.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn index 6a1013f8d..2558d5f3e 100644 --- a/doc/todo/auto_rebuild_on_template_change.mdwn +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -24,6 +24,7 @@ register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're used. Although, having every page declare an explicit dep on `page.tmpl` is perhaps a bit much; might be better to implement a special case for that one. Also, having the templates be copied to `destdir` is not desirable. +(However, if they're not copied, wikilinks to them will be broken. Hmm.) The risk is that a site might have `allowed_attachments` set to `templates/*` or `*.tmpl` something like that. I think such a configuration @@ -39,3 +40,8 @@ wikitemplates and in-wiki templates.) >> --[[Joey]] >>> I don't follow you. --[[KathrynAndersen]] + +>>>> If they don't render to output files, they clearly don't +>>>> need to be treated as wiki pages. (They need to be treated +>>>> as raw files anyway, because you don't want random users editing them +>>>> in the online editor.) --[[Joey]] -- cgit v1.2.3 From 11718519348382892d5c6fdb21b8e721c2413eb0 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 20 Apr 2010 01:32:19 -0400 Subject: similarity to internal pages --- doc/todo/auto_rebuild_on_template_change.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn index 2558d5f3e..2e4ba8e9a 100644 --- a/doc/todo/auto_rebuild_on_template_change.mdwn +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -24,7 +24,8 @@ register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're used. Although, having every page declare an explicit dep on `page.tmpl` is perhaps a bit much; might be better to implement a special case for that one. Also, having the templates be copied to `destdir` is not desirable. -(However, if they're not copied, wikilinks to them will be broken. Hmm.) +In a sense, these template would be like internal pages, except not wiki +pages, but raw files. The risk is that a site might have `allowed_attachments` set to `templates/*` or `*.tmpl` something like that. I think such a configuration -- cgit v1.2.3 From 52ccc03d10c532b3cf6335b00a9b60057061596b Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Tue, 20 Apr 2010 15:40:10 +0100 Subject: clarify whether the raw files would be put in destdir --- doc/todo/auto_rebuild_on_template_change.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn index 2e4ba8e9a..09a623427 100644 --- a/doc/todo/auto_rebuild_on_template_change.mdwn +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -46,3 +46,6 @@ wikitemplates and in-wiki templates.) >>>> need to be treated as wiki pages. (They need to be treated >>>> as raw files anyway, because you don't want random users editing them >>>> in the online editor.) --[[Joey]] + +>>>>> Just to be clear, the raw files would not be copied across to the output +>>>>> directory? -- [[Jon]] -- cgit v1.2.3 From 3b8f4f59d6720e5a77cae30eacc4c46582b1603b Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Tue, 20 Apr 2010 15:01:39 +0000 Subject: internal pages: the revenge? --- doc/todo/auto_rebuild_on_template_change.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn index 09a623427..b5c107915 100644 --- a/doc/todo/auto_rebuild_on_template_change.mdwn +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -49,3 +49,9 @@ wikitemplates and in-wiki templates.) >>>>> Just to be clear, the raw files would not be copied across to the output >>>>> directory? -- [[Jon]] + +>>>>>> Without modifying ikiwiki, they'd be copied to the output directory as +>>>>>> (e.g.) http://ikiwiki.info/templates/inlinepage.tmpl; to not copy them, +>>>>>> it'd either be necessary to make them be internal pages +>>>>>> (templates/inlinepage._tmpl) or special-case them in some other way. +>>>>>> --[[smcv]] -- cgit v1.2.3 From 4b4fdc85abba7200eed78eb473341e44fecc6087 Mon Sep 17 00:00:00 2001 From: "http://oblomov.myopenid.com/" Date: Tue, 20 Apr 2010 20:18:29 +0000 Subject: Clarifications --- doc/todo/Multiple_categorization_namespaces.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index 74e5bc812..a8ee6755c 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -80,9 +80,14 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t * Is this a field-name -> directory mapping? -- K.A. * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B. * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name. Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A. + * that's the idea. In your case you could have the linkbase of genre be fiction/genre, and it would be created if it was missing. -- G.B. * `queries` : list of template queries this type/attribute/field/whatever is exposed to * I'm not sure what you mean here. -- K.A. * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B. * Ah, do you mean that the input value is the same, but the output format is different? Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A. + * Actually this is about the same information appearing in different queries (e.g. NAME="FOO" and NAME="BAR"). Example: say that I defined a "Rubrica" field. I would want both tags and categories to appear in `categories` template query, but only tags would appear in the `tags` query, and only Rubrica values to appear in `rubrica` queries. The issue of different output formats was presented in the next paragraph instead. -- G.B. Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. + +One possibility could be to have the `queries` configuration allow a hash mapping query names to functions that would transform the data. Lacking that possibility, we might have to leave some predefined fields to have custom Perl-side treatment and leave custom fields to be untransformable. + -- cgit v1.2.3