[pmwiki-devel] Planned next features? (was pmwiki-2.2.0-beta17 released)

[Dominique Faure]

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 [1]...
>
> 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
> already allows us to create controls with custom javascript!".
>
> 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
> perform client-side input validation in javascript.  (Yes, some
> 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
like:

Group.Page:
[[#trailA]]
* [[fooA]]
* [[barA]]
[[#trailAend]]
* [[baz]]
[[#trailB]]
* [[fooB]]
* [[barB]]
[[#trailBend]]

instead of:

Group.Page:
(:include Group.TrailA:)
* [[baz]]
(:include Group.TrailB:)
[[#trailB]]
* [[fooB]]
* [[barB]]
[[#trailBend]]

Group.TrailA:
* [[fooA]]
* [[barA]]

Group.TrailB:
* [[fooB]]
* [[barB]]

which add two extraneous pages into the group. Then, the markup could be:

<<|[[Group.Page#trailA#trailAend]]|>>

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#a]]
* [[Page2#b]]
* [[Page3]]

which generate:

[[Page1]] <-> [[Page2]] <-> [[Page2]] <-> [[Page3]]

should this really be:

[[Page1]] <-> [[Page2#a]] <-> [[Page2#b]] <-> [[Page3]]

or:

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

Dom