[pmwiki-users] Planning for 2.2.0

[Patrick R. Michaud]

This message is just to outline my plans for PmWiki over the next
couple of weeks, as there are a lot of features and improvements
on tap.

Some of the features will involve reworking PmWiki internals a bit.
While I don't expect any of these changes to have significant impacts
on existing sites or recipes, there's always the chance that I'll 
overlook something.  Thus, in keeping with my standard version
numbering criteria, I'll start labeling these new feature releases 
as 2.2.0-beta so that administrators will know to look a bit
more closely before upgrading.

Here are some of my ideas and plans for 2.2; any comments or 
concerns about these are welcomed.


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.)

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".


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".


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.


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.


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.


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.)


7.  A blogging module will be available.  I'm not sure if this
will be provided by recipe or as part of the core distribution,
but either way it'll be fairly easy to activate in the core.
The blogging features will largely follow the description I 
gave late last year (i.e., using a (:blog:) markup to indicate
blog pages).


8.  The [[target | text | title]] markup (and its variants) discussed
on pmwiki-users may get added into the core.


9.  It will be possible for administrators and recipes to define
"virtual" pages; i.e., pages that always appear to exist even
if they haven't been created yet.  This will avoid problems of
links to non-existent category pages, etc.


10. The long-awaited (:input select ...:) markup will be added.


11. It will be easier to set default values for form textareas, 
radio buttons, and checkboxes from markup or from previously
submitted data.


12. We may add some ability to specify which form elements
should receive the input focus when a form appears in a page.
I haven't decided on a syntax for this yet, but it seems to be
needed for a variety of forms, both in PmWiki and in other
applications.


Those are my current plans for 2.2; they are of course subject
to change as we move along.  I'm hoping to have many (most?)
of these released in the very near future.

Thanks,

Pm