From a70c2518af7f48036a21d04c5b4070f3ea96002c Mon Sep 17 00:00:00 2001 From: David Riebenbauer Date: Fri, 16 Apr 2010 18:16:47 +0200 Subject: answer to clarification. --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 ++ 1 file changed, 2 insertions(+) (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 1259552bf..0ae025a13 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 @@ -236,6 +236,8 @@ wrong direction. >>>>> so it was necessary. (Another way to look at this is that >>>>> `%pagestate` is not the ideal data structure.) --[[Joey]] +>>>>> Ok, now I know what you mean. --[[David_Riebenbauer]] + >>> * `autoindex` forgets that a page was deleted when that page is >>> re-created -- cgit v1.2.3 From 720522859806d9cf50231ed6aa28085754713701 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Fri, 16 Apr 2010 17:51:51 +0000 Subject: ... and indeed there is a better way to store it --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 3 +++ 1 file changed, 3 insertions(+) (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 0ae025a13..8fc97578c 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 @@ -236,6 +236,9 @@ wrong direction. >>>>> so it was necessary. (Another way to look at this is that >>>>> `%pagestate` is not the ideal data structure.) --[[Joey]] +>>>>>> Aha! Having looked at [[plugins/write]] again, it turns out that what this +>>>>>> feature should really use is `%wikistate`, I think? :-) --[[smcv]] + >>>>> Ok, now I know what you mean. --[[David_Riebenbauer]] >>> * `autoindex` forgets that a page was deleted when that page is -- cgit v1.2.3 From ff5b73163f97110e83dd777cf7e14debebf85288 Mon Sep 17 00:00:00 2001 From: "http://oblomov.myopenid.com/" Date: Fri, 16 Apr 2010 18:20:29 +0000 Subject: Proposal for tags/meta/field coalescing --- doc/todo/Multiple_categorization_namespaces.mdwn | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index eb1f58cfa..ee3bbd88d 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -51,3 +51,22 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit >> I would like to point out however that there are some functional differences between categorization metadata vs other metadata that might suggest to keep fields and (my extended) tags separate. For examples, in feeds you'd want all categorization metadata to fall in one place, with some appropriate manipulation (which I still have to implement, by the way), while things like author or title would go to the corresponding feed item properties. Although it all would be possible with appropriate report or template juggling, having such default metadata handled natively looks like a bonus to me. >>> Whereas I prefer being able to control such things with templates, because it gives more flexibility AND control. - K.A. + +>>>> Flexibility and control is good for tuning and power-usage, but sensible defaults are a must for a platform to be usable out of the box without much intervention. Moreover, there's a possible problem with what kind of data must be passed over to templates. + +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) + +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 + +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