[pmwiki-users] Planning for 2.2.0

[Joachim Durchholz]

Patrick R. Michaud schrieb:
> 1.  Page links and page variables inside of included pages will
> become relative by default.  This means that if we're viewing 
> GroupA.ABC, and that page includes GroupB.DEF, then any links in 
> GroupB.DEF that look like [[XYZ]] will link to GroupB.XYZ
> (instead of GroupA.XYZ as happens now).  This seems to be more
> consistent with what authors expect.

 > In short, page variables and links that aren't fully qualified
 > will be treated as relative to the page in which they are written.
 > (Currently they use the page that is being browsed.)

It's also easier to understand what a link is doing.
With the existing semantics, when I see a [[XYZ]] link, I have to check 
all the places where the page is included (and make sure that the 
referred-to page exists). With the new semantics, I know where the link 
will refer to without having to check other pages - that's a clear win.

> As another example, if GroupB.DEF has {$FullName} markup in it, then
> it will result in "GroupB.DEF", even if GroupB.DEF is being included
> in another page.
> 
> Of course, there will be options available to cause PmWiki to
> use the previous behavior, and there will be a syntax for page
> variables that indicates "the currently browsed page" as opposed
> to "the page in which the variable is written".

This could be useful e.g. when setting up a group for pages intended to 
be reused across other groups.

> 2.  Page text variables (the {$:var} notation) will be part of the
> core.  They'll also work in pagelists.  This means that one will
> be able to grab text from fields defined in other pages.  The
> field markups I'm currently considering are:
> 
>     Name: Patrick Michaud                  (natural markup)
>     :Name:Patrick Michaud                  (definition list)
>     (:Name:Patrick Michaud:)               (directive form -- defines 
>                                             value but isn't displayed)
> 
> It's also possible that this last form will allow multi-line values --
> I haven't decided that yet.  Of course, recipes and administrators
> will be able to define their own patterns to be recognized.
> 
> As in #1 above, page text variables such as {$:var} will generally be 
> relative to the "page in which it is written" as opposed to 
> "currently browsed page".

Hmm... reworking Caveman's Fast Data recipe?

> 3.  The pagelist.php script has been largely refactored to be more
> extensible.  This will enable recipe authors to more easily add
> custom filters and sources into the pagelist processing without
> modifying the core.

I hope this doesn't affect performance.

> 4.  Using (:include PageName#xyz:)  will default to returning
> nothing if the target page doesn't have a [[#xyz]] anchor.
> Currently it seems to return the entire page.  There will also be
> configurable options to have (:include:) return an error message
> if a requested section doesn't exist.

Good.

On a tangent... I'm missing error diagnostics.
Currently, whenever you do something wrong, PmWiki does a mild effort at 
cleaning up the mess, but doesn't give you any error messages - the 
feedback is just "it doesn't work (in various ways)".
I know that retrofitting good error diagnostics is a bitch, but it would 
*tremendously* help.

Error messages probably shouldn't be displayed in normal view mode, but 
they do have their place in preview.

> 5.  There will be a "comment box" capability added into the core.
> Because of existing comment box recipes, the markup for
> comment boxes in the core will probably be something other than
> "(:commentbox:)".  I haven't decided exactly what to call it yet.  
> The core commenting capability will allow comments to be added at
> arbitrary points in pages, thus it's possible to collect comments 
> directly in the current page or to have comments stored in a
> separate pages.

Any ideas about spam filtering?

> 6.  There will be an UpdatePage() function available that will
> make it easy for scripts to change page contents such that
> page history, RecentChanges pages, notifications, etc. still
> take place.  (Currently this can be done only through the HandleEdit()
> function, which isn't general purpose.)

Woo-hoo!

Make that thing easily callable from the command line, and we have 
something that will open PmWiki for all kinds of scripting goodness. 
E.g. mail-to-wiki gateways, automatically updated weather pages (and 
whatever regularly-changing contents there is), deprecated-markup 
massaging, and what-have-you.

Regards,
Jo