]> sipb.mit.edu Git - ikiwiki.git/commitdiff
Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
authorJoey Hess <joey@kitenet.net>
Fri, 21 May 2010 17:47:18 +0000 (13:47 -0400)
committerJoey Hess <joey@kitenet.net>
Fri, 21 May 2010 17:47:18 +0000 (13:47 -0400)
doc/forum/debian_backports_update_someone_please.mdwn
doc/ikiwiki/directive/ftemplate.mdwn [new file with mode: 0644]
doc/ikiwiki/directive/report.mdwn [new file with mode: 0644]
doc/plugins/contrib/field.mdwn
doc/plugins/contrib/ftemplate.mdwn
doc/plugins/contrib/report.mdwn
doc/plugins/contrib/ymlfront.mdwn
doc/plugins/contrib/ymlfront/discussion.mdwn
doc/todo/Multiple_categorization_namespaces.mdwn
doc/users/jasonblevins.mdwn
doc/users/tupyakov_vladimir.mdwn [new file with mode: 0644]

index 66f5eb0c5f24666d8399e2040d5275985dfaf10a..a1366872f3098fbca5c4320d3278a834fbb6e3a1 100644 (file)
@@ -12,3 +12,5 @@ I'm just in the process of deploying ikiwiki and I'd love to use it in the html5
 >>> can take priority though. --[[Joey]] 
 
 >>>> Great! Thanks.
+
+>>>> Still not available in the backports; did you break the silence on the wire and got back to work [[Joey]]? 
diff --git a/doc/ikiwiki/directive/ftemplate.mdwn b/doc/ikiwiki/directive/ftemplate.mdwn
new file mode 100644 (file)
index 0000000..3009fc8
--- /dev/null
@@ -0,0 +1,106 @@
+The `ftemplate` directive is supplied by the [[!iki plugins/contrib/ftemplate desc=ftemplate]] plugin.
+
+This is like the [[ikiwiki/directive/template]] directive, with the addition
+that one does not have to provide all the values in the call to the template,
+because ftemplate can query structured data ("fields") using the
+[[plugins/contrib/field]] plugin.
+
+Templates are files that can be filled out and inserted into pages in
+the wiki, by using the ftemplate directive. The directive has an id
+parameter that identifies the template to use.
+
+Additional parameters can be used to fill out the template, in
+addition to the "field" values.  Passed-in values override the
+"field" values.
+
+There are two places where template files can live.  One is in the /templates
+directory on the wiki.  These templates are wiki pages, and can be edited from
+the web like other wiki pages.
+
+The second place where template files can live is in the global
+templates directory (the same place where the page.tmpl template lives).
+This is a useful place to put template files if you want to prevent
+them being edited from the web, and you don't want to have to make
+them work as wiki pages.
+
+### EXAMPLES
+
+#### Example 1
+
+PageA:
+
+    \[[!meta title="I Am Page A"]]
+    \[[!meta description="A is for Apple."]]
+    \[[!meta author="Fred Nurk"]]
+    \[[!ftemplate id="mytemplate"]]
+
+Template "mytemplate":
+
+    # <TMPL_VAR NAME="TITLE">
+    by <TMPL_VAR NAME="AUTHOR">
+
+    **Summary:** <TMPL_VAR NAME="DESCRIPTION">
+
+This will give:
+
+    <h1>I Am Page A</h1>
+    <p>by Fred Nurk</p>
+    <p><strong>Summary:</strong> A is for Apple.
+
+#### Example 2: Overriding values
+
+PageB:
+
+    \[[!meta title="I Am Page B"]]
+    \[[!meta description="B is for Banana."]]
+    \[[!meta author="Fred Nurk"]]
+    \[[!ftemplate id="mytemplate" title="Bananananananas"]]
+
+This will give:
+
+    <h1>Bananananananas</h1>
+    <p>by Fred Nurk</p>
+    <p><strong>Summary:</strong> B is for Banana.
+
+#### Example 3: Loops
+
+(this example uses the [[plugins/contrib/ymlfront]] plugin)
+
+Page C:
+
+    ---
+    BookAuthor: Georgette Heyer
+    BookTitle: Black Sheep
+    BookGenre:
+      - Historical
+      - Romance
+    ---
+    \[[ftemplate id="footemplate"]]
+
+    I like this book.
+
+Template "footemplate":
+
+    # <TMPL_VAR BOOKTITLE>
+    by <TMPL_VAR BOOKAUTHOR>
+
+    <TMPL_IF BOOKGENRE>(
+    <TMPL_LOOP GENRE_LOOP><TMPL_VAR BOOKGENRE>
+    <TMPL_UNLESS __last__>, </TMPL_UNLESS>
+    </TMPL_LOOP>
+    )</TMPL_IF>
+
+This will give:
+
+    <h1>Black Sheep</h1>
+    <p>by Georgette Heyer</p>
+
+    <p>(Historical, Romance)</p>
+
+    <p>I like this book.</p>
+
+### LIMITATIONS
+
+One cannot query the values of fields on pages other than the current
+page.  If you want to do that, check out the [[plugins/contrib/report]]
+plugin.
diff --git a/doc/ikiwiki/directive/report.mdwn b/doc/ikiwiki/directive/report.mdwn
new file mode 100644 (file)
index 0000000..8f8e6b4
--- /dev/null
@@ -0,0 +1,149 @@
+[[!toc]]
+The `report` directive is supplied by the [[!iki plugins/contrib/report desc=report]] plugin.
+
+This enables one to report on the structured data ("field" values) of
+multiple pages; the output is formatted via a template.  This depends
+on the [[plugins/contrib/field]] plugin.
+
+The pages to report on are selected by a PageSpec given by the "pages"
+parameter.  The template is given by the "template" parameter.
+The template expects the data from a single page; it is applied
+to each matching page separately, one after the other.
+
+Additional parameters can be used to fill out the template, in
+addition to the "field" values.  Passed-in values override the
+"field" values.
+
+There are two places where template files can live.  One is in the
+/templates directory on the wiki.  These templates are wiki pages, and
+can be edited from the web like other wiki pages.
+
+The second place where template files can live is in the global
+templates directory (the same place where the page.tmpl template lives).
+This is a useful place to put template files if you want to prevent
+them being edited from the web, and you don't want to have to make
+them work as wiki pages.
+
+## OPTIONS
+
+**template**: The template to use for the report.
+
+**pages**: A PageSpec to determine the pages to report on.
+
+**trail**: A page or pages to use as a "trail" page.
+
+When a trail page is used, the matching pages are limited to (a subset
+of) the pages which that page links to; the "pages" pagespec in this
+case, rather than selecting pages from the entire wiki, will select
+pages from within the set of pages given by the trail page.
+
+Additional space-separated trail pages can be given in this option.
+For example:
+
+    trail="animals/cats animals/dogs"
+
+This will take the links from both the "animals/cats" page and the
+"animals/dogs" page as the set of pages to apply the PageSpec to.
+
+**sort**: A SortSpec to determine how the matching pages should be sorted.
+
+**here_only**: Report on the current page only.
+
+This is useful in combination with "prev_" and "next_" variables to
+make a navigation trail.
+If the current page doesn't match the pagespec, then no pages will
+be reported on.
+
+### Headers
+
+An additional option is the "headers" option.  This is a space-separated
+list of field names which are to be used as headers in the report.  This
+is a way of getting around one of the limitations of HTML::Template, that
+is, not being able to do tests such as
+"if this-header is not equal to previous-header".
+
+Instead, that logic is performed inside the plugin.  The template is
+given parameters "HEADER1", "HEADER2" and so on, for each header.
+If the value of a header field is the same as the previous value,
+then HEADER**N** is set to be empty, but if the value of the header
+field is new, then HEADER**N** is given that value.
+
+#### Example
+
+Suppose you're writing a blog in which you record "moods", and you
+want to display your blog posts by mood.
+
+    \[[!report template="mood_summary"
+    pages="blog/*"
+    sort="Mood Date title"
+    headers="Mood"]]
+
+The "mood_summary" template might be like this:
+
+    <TMPL_IF NAME="HEADER1">
+    ## <TMPL_VAR NAME="HEADER1">
+    </TMPL_IF>
+    ### <TMPL_VAR NAME="TITLE">
+    (<TMPL_VAR NAME="DATE">) \[[<TMPL_VAR NAME="PAGE">]]
+    <TMPL_VAR NAME="DESCRIPTION">
+    
+### Advanced Options
+
+The following options are used to improve efficiency when dealing
+with large numbers of pages; most people probably won't need them.
+
+**doscan**:
+
+Whether this report should be called in "scan" mode; if it is, then
+the pages which match the pagespec are added to the list of links from
+this page.  This can be used by *another* report by setting this
+page to be a "trail" page in *that* report.
+It is not possible to use "trail" and "doscan" at the same time.
+By default, "doscan" is false.
+
+## TEMPLATE PARAMETERS
+
+The templates are in HTML::Template format, just as [[plugins/template]] and
+[[ftemplate]] are.  The parameters passed in to the template are as follows:
+
+### Fields
+
+The structured data from the current matching page.  This includes
+"title" and "description" if they are defined.
+
+### Common values
+
+Values known for all pages: "page", "destpage".  Also "basename" (the
+base name of the page).
+
+### Passed-in values
+
+Any additional parameters to the report directive are passed to the
+template; a parameter will override the matching "field" value.
+For example, if you have a "Mood" field, and you pass Mood="bad" to
+the report, then that will be the Mood which is given for the whole
+report.
+
+Generally this is useful if one wishes to make a more generic
+template and hide or show portions of it depending on what
+values are passed in the report directive call.
+
+For example, one could have a "hide_mood" parameter which would hide
+the "Mood" section of your template when it is true, which one could
+use when the Mood is one of the headers.
+
+### Prev_ And Next_ Items
+
+Any of the above variables can be prefixed with "prev_" or "next_"
+and that will give the previous or next value of that variable; that is,
+the value from the previous or next page that this report is reporting on.
+This is mainly useful for a "here_only" report.
+
+### Headers
+
+See the section on Headers.
+
+### First and Last
+
+If this is the first page-record in the report, then "first" is true.
+If this is the last page-record in the report, then "last" is true.
index 09646d28ad2dfdf94ab3aa67e985898b2b1e85a5..dce2d891c9083c9da9e24a2ecadf41ab32a3214a 100644 (file)
@@ -13,9 +13,22 @@ IkiWiki::Plugin::field - front-end for per-page record fields.
     # simple registration
     field_register => [qw{meta}],
 
+    # simple registration with priority
+    field_register => {
+       meta => 'last'
+       foo => 'DD'
+    },
+
     # allow the config to be queried as a field
     field_allow_config => 1,
 
+    # flag certain fields as "tags"
+    field_tags => {
+       BookAuthor => '/books/authors',
+       BookGenre => '/books/genres',
+       MovieGenre => '/movies/genres',
+    }
+
 ## DESCRIPTION
 
 This plugin is meant to be used in conjunction with other plugins
@@ -25,13 +38,14 @@ are fields in that record.  This can include the meta-data for that page,
 such as the page title.
 
 Plugins can register a function which will return the value of a "field" for
-a given page.  This can be used in three ways:
+a given page.  This can be used in a few ways:
 
 * In page templates; all registered fields will be passed to the page template in the "pagetemplate" processing.
 * In PageSpecs; the "field" function can be used to match the value of a field in a page.
+* In SortSpecs; the "field" function can be used for sorting pages by the value of a field in a page.
 * By other plugins, using the field_get_value function, to get the value of a field for a page, and do with it what they will.
 
-## OPTIONS
+## CONFIGURATION OPTIONS
 
 The following options can be set in the ikiwiki setup file.
 
@@ -46,28 +60,77 @@ keys of the config hash are the field names.
 
     field_register => [qw{meta}],
 
-A list of plugin-IDs to register.  This assumes that the plugins in
-question store data in the %pagestatus hash using the ID of that plugin,
-and thus the field values are looked for there.
+    field_register => {
+       meta => 'last'
+       foo => 'DD'
+    },
+
+A hash of plugin-IDs to register.  The keys of the hash are the names of the
+plugins, and the values of the hash give the order of lookup of the field
+values.  The order can be 'first', 'last', 'middle', or an explicit order
+sequence between 'AA' and 'ZZ'.  If the simpler type of registration is used,
+then the order will be 'middle'.
+
+This assumes that the plugins in question store data in the %pagestatus hash
+using the ID of that plugin, and thus the field values are looked for there.
 
 This is the simplest form of registration, but the advantage is that it
 doesn't require the plugin to be modified in order for it to be
 registered with the "field" plugin.
 
-## PageSpec
+**field_tags**
+
+    field_tags => {
+       BookAuthor => '/books/authors',
+       BookGenre => '/books/genres',
+       MovieGenre => '/movies/genres',
+    }
 
-The "field" PageSpec function can be used to match the value of a field for a page.
+A hash of fields and their associated pages.  This provides a faceted
+tagging system.
 
-**field(*name* *glob*)**
+The way this works is that a given field-name will be associated with a given
+page, and the values of that field will be linked to sub-pages of that page.
 
 For example:
 
-field(bar Foo*) will match if the "bar" field starts with "Foo".
+       BookGenre: SF
+
+will link to "/books/genres/SF", with a link-type of "bookgenre".
 
-**destfield(*name* *glob*)**
+## PageSpec
+
+The `field` plugin provides a few PageSpec functions to match values
+of fields for pages.
+
+* field
+  * **field(*name* *glob*)**
+  * field(bar Foo\*) will match if the "bar" field starts with "Foo".
+* destfield
+  * **destfield(*name* *glob*)**
+  * as for "field" but matches against the destination page (i.e when the source page is being included in another page).
+* field_item
+  * **field_item(*name* *glob*)**
+  * field_item(bar Foo) will match if one of the values of the "bar" field is "Foo".
+* destfield_item
+  * **destfield_item(*name* *glob*)**
+  * as for "field_item" but matches against the destination page.
+* field_tagged
+  * **field_tagged(*name* *glob*)**
+  * like `tagged`, but this uses the tag-bases and link-types defined in the `field_tags` configuration option.
+* destfield_tagged
+  * **destfield_tagged(*name* *glob*)**
+  * as for "field_tagged" but matches against the destination page.
+
+## SortSpec
+
+The "field" SortSpec function can be used to sort a page depending on the value of a field for that page.  This is used for directives that take sort parameters, such as **inline** or **report**.
+
+field(*name*)
 
-is the same, except that it tests the destination page (that is, in cases
-when the source page is being included in another page).
+For example:
+
+sort="field(bar)" will sort by the value og the "bar" field.
 
 ## FUNCTIONS
 
@@ -75,16 +138,18 @@ when the source page is being included in another page).
 
 field_register(id=>$id);
 
-Register a plugin as having field data.  The above form is the simplest, where the field value
-is looked up in the %pagestatus hash under the plugin-id.
+Register a plugin as having field data.  The above form is the simplest, where
+the field value is looked up in the %pagestatus hash under the plugin-id.
 
 Additional Options:
 
 **call=>&myfunc**
 
-A reference to a function to call rather than just looking up the value in the %pagestatus hash.
-It takes two arguments: the name of the field, and the name of the page.  It is expected to return
-the value of that field, or undef if there is no field by that name.
+A reference to a function to call rather than just looking up the value in the
+%pagestatus hash.  It takes two arguments: the name of the field, and the name
+of the page.  It is expected to return (a) an array of the values of that field
+if "wantarray" is true, or (b) a concatenation of the values of that field
+if "wantarray" is not true, or (c) undef if there is no field by that name.
 
     sub myfunc ($$) {
        my $field = shift;
@@ -92,22 +157,38 @@ the value of that field, or undef if there is no field by that name.
 
        ...
 
-       return $value;
+       return (wantarray ? @values : $value);
     }
 
 **first=>1**
 
-Set this to be called first in the sequence of calls looking for values.  Since the first found
-value is the one which is returned, ordering is significant.
+Set this to be called first in the sequence of calls looking for values.  Since
+the first found value is the one which is returned, ordering is significant.
+This is equivalent to "order=>'first'".
 
 **last=>1**
 
-Set this to be called last in the sequence of calls looking for values.  Since the first found
-value is the one which is returned, ordering is significant.
+Set this to be called last in the sequence of calls looking for values.  Since
+the first found value is the one which is returned, ordering is significant.
+This is equivalent to "order=>'last'".
+
+**order=>$order**
+
+Set the explicit ordering in the sequence of calls looking for values.  Since
+the first found value is the one which is returned, ordering is significant.
+
+The values allowed for this are "first", "last", "middle", or a two-character
+ordering-sequence between 'AA' and 'ZZ'.
 
 ### field_get_value($field, $page)
 
-Returns the value of the field for that page, or undef if none is found.
+    my @values = field_get_value($field, $page);
+
+    my $value = field_get_value($field, $page);
+
+Returns the values of the field for that page, or undef if none is found.
+Note that it will return an array of values if you ask for an array,
+and a scalar value if you ask for a scalar.
 
 ## DOWNLOAD
 
index fba51e1c2a7ac3e21bbb1ae20242bc58ef2c4218..d82867f948d31ffd852f0a16f2442fcb1572972c 100644 (file)
@@ -1,85 +1,16 @@
 [[!template id=plugin name=ftemplate author="[[rubykat]]"]]
 [[!tag type/meta type/format]]
-[[!toc]]
-## NAME
 
-IkiWiki::Plugin::ftemplate - field-aware structured template plugin
+This plugin provides the [[ikiwiki/directive/ftemplate]] directive.
 
-## SYNOPSIS
+This is like the [[ikiwiki/directive/template]] directive, with the addition
+that one does not have to provide all the values in the call to the template,
+because ftemplate can query structured data ("fields") using the [[field]]
+plugin.
 
-    # activate the plugin
-    add_plugins => [qw{goodstuff ftemplate ....}],
-
-## DESCRIPTION
-
-This plugin provides the **ftemplate** directive.  This is like
-the [[ikiwiki/directive/template]] directive, with the addition that one does not
-have to provide all the values in the call to the template,
-because ftemplate can query structured data ("fields") using
-the [[field]] plugin.
-
-Templates are files that can be filled out and inserted into pages in
-the wiki, by using the ftemplate directive. The directive has an id
-parameter that identifies the template to use.
-
-Additional parameters can be used to fill out the template, in
-addition to the "field" values.  Passed-in values override the
-"field" values.
-
-There are two places where template files can live.  One is, as with the
-[[plugins/template]] plugin, in the /templates directory on the wiki.  These
-templates are wiki pages, and can be edited from the web like other wiki
-pages.
-
-The second place where template files can live is in the global
-templates directory (the same place where the page.tmpl template lives).
-This is a useful place to put template files if you want to prevent
-them being edited from the web, and you don't want to have to make
-them work as wiki pages.
-
-### EXAMPLES
-
-#### Example 1
-
-PageA:
-
-    \[[!meta title="I Am Page A"]]
-    \[[!meta description="A is for Apple."]]
-    \[[!meta author="Fred Nurk"]]
-    \[[!ftemplate id="mytemplate"]]
-
-Template "mytemplate":
+## Activate the plugin
 
-    # <TMPL_VAR NAME="TITLE">
-    by <TMPL_VAR NAME="AUTHOR">
-
-    **Summary:** <TMPL_VAR NAME="DESCRIPTION">
-
-This will give:
-
-    <h1>I Am Page A</h1>
-    <p>by Fred Nurk</p>
-    <p><strong>Summary:</strong> A is for Apple.
-
-#### Example 2: Overriding values
-
-PageB:
-
-    \[[!meta title="I Am Page B"]]
-    \[[!meta description="B is for Banana."]]
-    \[[!meta author="Fred Nurk"]]
-    \[[!ftemplate id="mytemplate" title="Bananananananas"]]
-
-This will give:
-
-    <h1>Bananananananas</h1>
-    <p>by Fred Nurk</p>
-    <p><strong>Summary:</strong> B is for Banana.
-
-### LIMITATIONS
-
-One cannot query the values of fields on pages other than the current
-page.
+    add_plugins => [qw{goodstuff ftemplate ....}],
 
 ## PREREQUISITES
 
index c364d4a3a100ac585214520594da940f1831f7b5..0bd5392c62c3c7c2cfca280871ac724aae360c69 100644 (file)
 [[!template id=plugin name=report author="[[rubykat]]"]]
 [[!tag type/meta type/format]]
-[[!toc]]
-## NAME
-
 IkiWiki::Plugin::report - Produce templated reports from page field data.
 
-## SYNOPSIS
-
-    # activate the plugin
-    add_plugins => [qw{goodstuff report ....}],
-
-    \[[!report template="blog_summary"
-    pages="blog/*"
-    sort="mtime"]]
-
-## DESCRIPTION
-
-This plugin provides the **report** directive.  This enables one to report on
-the structured data ("field" values) of multiple pages; the output is formatted
-via a template.  This depends on the [[plugins/contrib/field]] plugin.
-
-The pages to report on are selected by a PageSpec given by the "pages"
-parameter.  The template is given by the "template" parameter.
-The template expects the data from a single page; it is applied
-to each matching page separately, one after the other.
-
-Additional parameters can be used to fill out the template, in
-addition to the "field" values.  Passed-in values override the
-"field" values.
-
-There are two places where template files can live.  One, as with the
-[[plugins/template]] plugin, is in the /templates directory on the wiki.  These
-templates are wiki pages, and can be edited from the web like other wiki
-pages.
-
-The second place where template files can live is in the global
-templates directory (the same place where the page.tmpl template lives).
-This is a useful place to put template files if you want to prevent
-them being edited from the web, and you don't want to have to make
-them work as wiki pages.
-
-## OPTIONS
-
-**template**: The template to use for the report.
-
-**pages**: A PageSpec to determine the pages to report on.
-
-**sort**: How the matching pages should be sorted.  Sorting criteria are separated by spaces.
-
-The possible values for sorting are:
-
-* **page**: Sort by the full page ID.
-* **pagename**: Sort by the base page name.
-* **pagename_natural**: Sort by the base page name, using Sort::Naturally if it is installed.
-* **mtime**: Sort by the page modification time.
-* **age**: Sort by the page creation time, newest first.
-
-Any other value is taken to be a field name to sort by.
-If a sort value begins with a minus (-) then the order for that field is reversed.
-
-### Headers
-
-An additional option is the "headers" option.  This is a space-separated
-list of field names which are to be used as headers in the report.  This
-is a way of getting around one of the limitations of HTML::Template, that
-is, not being able to do tests such as
-"if this-header is not equal to previous-header".
-
-Instead, that logic is performed inside the plugin.  The template is
-given parameters "HEADER1", "HEADER2" and so on, for each header.
-If the value of a header field is the same as the previous value,
-then HEADER**N** is set to be empty, but if the value of the header
-field is new, then HEADER**N** is given that value.
-
-#### Example
+This plugin provides the [[ikiwiki/directive/report]] directive.  This enables
+one to report on the structured data ("field" values) of multiple pages; the
+output is formatted via a template.  This depends on the
+[[plugins/contrib/field]] plugin.
 
-Suppose you're writing a blog in which you record "moods", and you
-want to display your blog posts by mood.
 
-    \[[!report template="mood_summary"
-    pages="blog/*"
-    sort="Mood Date title"
-    headers="Mood"]]
+## Activate the plugin
 
-The "mood_summary" template might be like this:
-
-    <TMPL_IF NAME="HEADER1">
-    ## <TMPL_VAR NAME="HEADER1">
-    </TMPL_IF>
-    ### <TMPL_VAR NAME="TITLE">
-    (<TMPL_VAR NAME="DATE">) \[[<TMPL_VAR NAME="PAGE">]]
-    <TMPL_VAR NAME="DESCRIPTION">
-    
-### Advanced Options
-
-The following options are used to improve efficiency when dealing
-with large numbers of pages; most people probably won't need them.
-
-**trail**:
-
-A page or pages to use as a "trail" page.  When a trail page is used,
-the matching pages are limited to (a subset of) the pages which that
-page links to; the "pages" pagespec in this case, rather than selecting
-pages from the entire wiki, will select pages from within the set of pages
-given by the trail page.
-
-**doscan**:
-
-Whether this report should be called in "scan" mode; if it is, then
-the pages which match the pagespec are added to the list of links from
-this page.  This can be used by *another* report by setting this
-page to be a "trail" page in *that* report.
-It is not possible to use "trail" and "doscan" at the same time.
-By default, "doscan" is false.
-
-## TEMPLATE PARAMETERS
-
-The templates are in HTML::Template format, just as [[plugins/template]] and
-[[ftemplate]] are.  The parameters passed in to the template are as follows:
-
-***fields***:
-
-The structured data from the current matching page.  This includes
-"title" and "description" if they are defined.
-
-***common values***:
-
-Values known for all pages: "page", "destpage".  Also "basename" (the base name of the page).
-
-***passed-in values***:
-
-Any additional parameters to the report directive are passed to the
-template; a parameter will override the matching "field" value.
-For example, if you have a "Mood" field, and you pass Mood="bad" to
-the report, then that will be the Mood which is given for the whole
-report.
-
-Generally this is useful if one wishes to make a more generic
-template and hide or show portions of it depending on what
-values are passed in the report directive call.
-
-For example, one could have a "hide_mood" parameter which would hide
-the "Mood" section of your template when it is true, which one could
-use when the Mood is one of the headers.
-
-***headers***:
-
-See the section on Headers.
-
-***first and last***:
-
-If this is the first page-record in the report, then "first" is true.
-If this is the last page-record in the report, then "last" is true.
+    # activate the plugin
+    add_plugins => [qw{goodstuff report ....}],
 
 ## PREREQUISITES
 
index f4438f23c11656c38272cbfa1d6a68f62aba81e2..6dd8ed532ad07d9873ae45be37ad9a70d7b53cef 100644 (file)
@@ -42,7 +42,7 @@ That will be htmlized using the page-type of the page-file.
 
 ### Accessing the Data
 
-There are three ways to access the data given in the YAML section.
+There are a few ways to access the data given in the YAML section.
 
 * [[getfield]] plugin
 
@@ -83,6 +83,10 @@ There are three ways to access the data given in the YAML section.
 
        When running on the Sprongle system, the Foo function returns incorrect data.
 
+* [[report]] plugin
+
+  The **report** plugin is like the [[ftemplate]] plugin, but it reports on multiple pages, rather than just the current page.
+
 * write your own plugin
 
   In conjunction with the [[field]] plugin, you can write your own plugin to access the data.
index 3ad02af296b39f166556066ae80d439795c0f7b5..b5c08fedd23b0fa0a1cbd21dc97bf14ba198f7bb 100644 (file)
@@ -9,3 +9,5 @@ Joey's code in IkiWiki::Setup::Yaml. Please consider merging :-) --[[smcv]]
 >> Sorry, I accidentally removed `field-etc` by pushing with `--mirror` from a
 >> different checkout. I've put it back; it's a branch from your `ikiplugins.git`,
 >> so yes, the code should be in `IkiWiki/Plugin`. --[[smcv]]
+
+>>> Done a while back, but now I've actually pushed to my repo. --[[KathrynAndersen]]
index a8ee6755c068a530b147272698d6cb9c4810e738..3e9f8feaa8216fbff9657a887ea94e4ad530bf21 100644 (file)
@@ -91,3 +91,13 @@ Where this approach is limiting is on the kind of data that is passed to (templa
 
 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]]
index b50e4844a04f30a21fd3c3d9e2b00fb94a3ca3d6..e4a459e30763b64615bfbb6d890bd550fec8aed6 100644 (file)
@@ -1,66 +1,46 @@
 [[!meta title="Jason Blevins"]]
 
-I'm currently hosting a private ikiwiki for keeping research notes
-which, with some patches and a plugin (below), will
-convert inline [[todo/LaTeX]] expressions to [[MathML]].  I'm working towards a
-patchset and instructions for others to do the same.
-
-I've setup a test ikiwiki [here](http://xbeta.org/colab/) where I've
-started keeping a few notes on my progress.  There is an example of
-inline [[todo/SVG]] on the homepage (note that the logo scales along with the
-font size).  There are a few example mathematical expressions in the
-[sandbox](http://xbeta.org/colab/sandbox/).  The MathML is generated
-automatically from inline LaTeX expressions using an experimental
-plugin I'm working on.
-
-My (also MathML-enabled) homepage: <http://jblevins.org/> (still using
-Blosxom...maybe one day I'll convert it to ikiwiki...)
-
-Current ikiwki issues of interest:
-
- * [[bugs/recentchanges_feed_links]]
- * [[bugs/HTML_inlined_into_Atom_not_necessarily_well-formed]]
- * [[plugins/toc/discussion]]
- * [[todo/BibTeX]]
- * [[todo/svg]]
- * [[todo/Option_to_make_title_an_h1?]]
- * [[bugs/SVG_files_not_recognized_as_images]]
+I am a former Ikiwiki user who wrote several plugins and patches
+related to MathML, [[SVG|todo/svg]], and [[todo/syntax highlighting]].
+Some related links and notes are archived below.
+
+Homepage: <http://jblevins.org/>
 
 ## Plugins
 
-These plugins are experimental.  Use them at your own risk.  Read the
-perldoc documentation for more details.  Patches and suggestions are
-welcome.
+The following [plugins](http://jblevins.org/projects/ikiwiki/)
+are no longer maintained, but please feel free to use, modify, and
+redistribute them.  Read the corresponding perldoc documentation for
+more details.
 
- * [mdwn_itex][] - Works with the [[`mdwn`|plugins/mdwn]] plugin to convert inline [[todo/LaTeX]]
-   expressions to [[MathML]] using `itex2MML`.
+ * [mdwn_itex][] - Works with the [[`mdwn`|plugins/mdwn]] plugin to convert
+   inline [[todo/LaTeX]] expressions to MathML using `itex2MML`.
 
  * [h1title][] - If present, use the leading level 1 Markdown header to
    set the page title and remove it from the page body.
 
  * [code][] - Whole file and inline code snippet [[todo/syntax highlighting]]
    via GNU Source-highlight.  The list of supported file extensions is
-   configurable.  There is also some preliminary [documentation][code-doc].
-   See the [FortranWiki](http://fortranwiki.org) for examples.
+   configurable.
 
- * [metamail][] - a plugin for loading metadata from [[email]]-style
+ * [metamail][] - a plugin for loading metadata from email-style
    headers at top of a file (e.g., `title: Page Title` or
    `date: November 2, 2008 11:14 EST`).
 
- * [pandoc][] - [[ikiwiki/Markdown]] page processing via [Pandoc](http://johnmacfarlane.net/pandoc/) (a Haskell library for converting from one markup format to another).  [[todo/LaTeX]] and
+ * [pandoc][] - [[ikiwiki/Markdown]] page processing via
+   [Pandoc](http://johnmacfarlane.net/pandoc/) (a Haskell library for
+   converting from one markup format to another).  [[todo/LaTeX]] and
    [[reStructuredText|plugins/rst]] are optional.
 
  * [path][] - Provides path-specific template conditionals such as
    `IS_HOMEPAGE` and `IN_DIR_SUBDIR`.
 
- [mdwn_itex]: http://code.jblevins.org/ikiwiki/plugins.git/plain/mdwn_itex.pm
- [h1title]: http://code.jblevins.org/ikiwiki/plugins.git/plain/h1title.pm
- [code]: http://code.jblevins.org/ikiwiki/plugins.git/plain/code.pm
- [code-doc]: http://code.jblevins.org/ikiwiki/plugins.git/plain/code.text
- [metamail]: http://code.jblevins.org/ikiwiki/plugins.git/plain/metamail.pm
- [pandoc]: http://code.jblevins.org/ikiwiki/plugins.git/plain/pandoc.pm
- [path]: http://code.jblevins.org/ikiwiki/plugins.git/plain/path.pm
-
+ [mdwn_itex]: http://jblevins.org/git/ikiwiki/plugins.git/plain/mdwn_itex.pm
+ [h1title]: http://jblevins.org/git/ikiwiki/plugins.git/plain/h1title.pm
+ [code]: http://jblevins.org/projects/ikiwiki/code
+ [metamail]: http://jblevins.org/git/ikiwiki/plugins.git/plain/metamail.pm
+ [pandoc]: http://jblevins.org/git/ikiwiki/plugins.git/plain/pandoc.pm
+ [path]: http://jblevins.org/git/ikiwiki/plugins.git/plain/path.pm
 
 ## MathML and SVG support
 
@@ -105,5 +85,5 @@ optimal solution is to force users to preview the page before saving.
 That way if someone introduces invalid XHTML then they can't save the
 page in the first place (unless they post directly to the right URL).
 
- [template-patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=templates/page.tmpl;h=380ef699fa72223744eb5c1ee655fb79aa6bce5b;hp=9084ba7e11e92a10528b2ab12c9b73cf7b0f40a7;hb=416d5d1b15b94e604442e4e209a30dee4b77b684;hpb=ececf4fb8766a4ff7eff943b3ef600be81a0df49
- [cgi-patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=commitdiff;h=fa538c375250ab08f396634135f7d79fce2a9d36
+ [template-patch]: http://jblevins.org/git/ikiwiki.git/commit/?h=xbeta&id=416d5d1b15b94e604442e4e209a30dee4b77b684
+ [cgi-patch]: http://jblevins.org/git/ikiwiki.git/commit/?id=fa538c375250ab08f396634135f7d79fce2a9d36
diff --git a/doc/users/tupyakov_vladimir.mdwn b/doc/users/tupyakov_vladimir.mdwn
new file mode 100644 (file)
index 0000000..95f85ad
--- /dev/null
@@ -0,0 +1 @@
+всем привет!