[pmwiki-devel] Planned next features? (was pmwiki-2.2.0-beta17 released)
dominique.faure at gmail.com
Thu Dec 14 15:55:05 CST 2006
On 12/14/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Thu, Dec 14, 2006 at 03:57:58PM +0100, Dominique Faure wrote:
> > Could you provide us some hints on what features you planned for next
> > releases and when will they occur?
> http://www.pmwiki.org/wiki/PmWiki/RoadMap .
I should have read it before asking...
> > To not been mistaken, I don't want to put any more pressure on you ;)
> > but I think it would be nice to provide us rough guidelines to avoid
> > recipe writers becoming (too rapidly) wheels (re)inventors ...
> In the case of (:input jumpbox:)... I didn't even realize that
> it would be possible to so easily customize the (:input select ...:)
> markup to provide jumpbox capabilities until Hans mentioned it earlier
> this week. So, it's not that I had planned to do it and simply didn't
> tell anyone, it was an "Aha!" moment of "Oh! The forms.php code
> For example, I'm just now realizing that the current forms.php
> script ought to make it relatively easy for administrators and
> recipe writers to create custom "(:input ...:)" controls that
> applications would still need to provide server-side input
> validation as well, but many times client-side validation is
> sufficient or a useful preliminary-check.)
That's a usual distinctiveness for well designed things ;)
> > ...more precisely, I would really appreciate to know your feelings about
> > trails.
> I don't have trails in the RoadMap yet, but they're certainly going
> to become more customizable than they currently are. I'm still
> working out syntax and configuration options.
My trail concerns are essentially tighted to the following
annoyances/limitations of the current implementation:
1) There's no way to "limit" a trail extend to a portion of a single
page. I would love having something closer to the (:include:) concept
which add two extraneous pages into the group. Then, the markup could be:
2) For now, the trail links must be strictly the 1st thing encountered
on the list item definition. Couldn't this be a bit relaxed and
(optionally) accept the 1st link link encountered ?
(I've not explored the mailing list archives very deep, but I'm sure
this point should have already generated a noticeable amount of mail).
3) This is perhaps a bug, but the current implementation doesn't
handle very well anchored links such as:
[[Page1]] <-> [[Page2]] <-> [[Page2]] <-> [[Page3]]
should this really be:
[[Page1]] <-> [[Page2#a]] <-> [[Page2#b]] <-> [[Page3]]
[[Page1]] <-> [[Page2]] <-> [[Page3]]
> It's likely that at some point (but probably not before 2.2.0)
> PmWiki will support a way to navigate trails based on pagelists.
> I don't know that the core will soon add the ability to create
> a trail from a pagelist, as I'm a little concerned about the
> performance ramifications of doing that, and I really don't
> have a markup for it that I like. The markup question is the
> more important of the two at the moment -- with a good markup
> I could envision this possibly being added to the core very quickly.
Last but not least, It would be nice to manage to "re-skin" the trail
markup output without having to rewrite the whole script (as I've
already done into a still-not-released-but-should-I-really-do-it
More information about the pmwiki-devel