[pmwiki-users] Planning for 2.2.0

[Henrik Bechmann]

Patrick,

Would it make sense to add {$PageCreationDate} and {$PageCreatedBy} page 
variables at this point? Together with {$LastModified} and 
{$LastModifiedBy} might provide good options for listing pages, or even 
for listing blog sections (though I'm not sure it would apply to the 
latter...).

BTW, I'm *very* glad to see the directive (hidden) form of {$:var} 
creation. (eg. "(:parentnode:Group.Page:)"<evil grin>).

I take it the space after the colon differentiates the natural form from 
the InterMap form?

Looks great!!

- Henrik

Patrick R. Michaud wrote:
> 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
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>   

-- 

Henrik Bechmann
www.osscommons.ca
www.bechmannsoftware.com
Webmaster, www.dufferinpark.ca