[pmwiki-users] Planning for 2.2.0

[Crisses]

On Sep 21, 2006, at 11:30 PM, Patrick R. Michaud wrote:

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

This makes sense.

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

This also makes sense.

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

This is sensible as well, as long as there's a way to get the link  
relative to the parent/calling 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".

*thumbs up*

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

I think this is something many of us are waiting on the edge of our  
seats for.  At least the Pagelist part :)

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

Yippie!  More hooks!

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

Sounds good.

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

How about "remark"s?  (:remarkbox:) ?

or (:pmcommentbox:)

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

This has been a long LONG time coming.  There hasn't been an email- 
 >page for a long long time, for example.  It might also warrant  
changes to recipes like xmlrpc.

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

I don't understand why we'd have this as part of the core  
distribution.  Blog != wiki, wiki != blog.

As a recipe I'm all for it.  Similarly, I wouldn't want the shopping  
cart as a part of the core, and I do want it as a recipe.

I think the idea of the PmWiki core being unbloated and slender is  
brilliant, and adding the blog to the core would be extraneous.  I  
have a bunch of wikis without blogging and don't need blogging. :)

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

I missed this one -- so I'm confused....  target, link text -- what's  
title?

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

Hrm.  Why not create the pages?

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

Another yippie!

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

Ditto.

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

Why would it be "elements"?  Wouldn't only one page element have  
focus?  Just like you do "selected" can't you have a way of choosing  
"focus"?

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

And we're very grateful! :)

Crisses