blogspam: Don't check modifications from admins for spam, and also allow the blogspam...

[git.ikiwiki.info.git] / doc / todo / Multiple_categorization_namespaces.mdwn

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 1861d860cf2f3eec688d25f5ea33f9318bc019eb..3e9f8feaa8216fbff9657a887ea94e4ad530bf21 100644 (file)
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -62,19 +62,42 @@ 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.
    * 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.
 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.
 
 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.
 * `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.
 * `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.
+             * 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.
 * `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). 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.
+
+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.
+
+-----
+
+I've now updated the [[plugins/contrib/field]] plugin to have:
+
+* arrays (multi-valued fields)
+* the "linkbase" option as mentioned above (called field_tags), where the linktype is the field name.
+
+I've also updated [[plugins/contrib/ftemplate]] and [[plugins/contrib/report]] to be able to use multi-valued fields, and [[plugins/contrib/ymlfront]] to correctly return multi-valued fields when they are requested.
+
+--[[KathrynAndersen]]