[pmwiki-users] Edit page extensions

Patrick R. Michaud pmichaud at pobox.com
Mon Apr 25 15:41:52 CDT 2005


On Mon, Apr 25, 2005 at 09:42:43PM +0200, Joachim Durchholz wrote:
> >and "Main" is a good choice because almost nobody wants to use it for
> >anything else.  :-)
> 
> New admins tend to not bother with groups, so everything is placed in
> Main because it's so simple. End result: a tangle of special and normal
> pages.

Nice point.

> Keeping ears pricked for that...

It ended up being different than I expected.  :-)

> >Oh, this is no problem -- the location of the edit page form is going
> >to be in a $...Fmt variable, so it can easily be made group-specific.
> >
> Worse, we leave site admins out in the cold finding good (i.e. unlikely
> to collide) names for these administrative pages. And things will end up
> being named differently in different groups. And we'll have trouble
> doing fallback mechanisms (not defined in group -> look in the sitewide
> configuration page -> oops, that's called differently).

PmWiki already handles fallbacks quite nicely in a number of areas
(skins, <!--wiki:--> markup, language translations, CSS files);
I see no reason why it would be any more difficult here.

> I've also been thinking about using some special character as prefix for
> special pages. 

Good idea -- not sure it'll work out.  Worth keeping in mind.  It
certainly makes filtering them out of search lists a bit easier.

> >http://www.pmwiki.org/wiki/PmWiki/HierarchicalGroups
> 
> Sorry, my question was based on reading that page and wanting to know more.
> Why is it felt that hierarchies don't give any additional power or
> flexibility? (They certainly seem to do.)

I've only run across one real-world (i.e., practical) example where 
hierarchical groups were demonstrably more powerful than what could
be done with the current flat namespace.  But the problems outweigh
the benefits...

> What's the problems with page referencing?

It's almost impossible to come up with a good syntax for relative
links to pages in other groups or subgroups in the hierarchy.  At 
first people think "oh, it's obvious -- just do it this way...", 
only it doesn't actually work out when you look at all of the
cases.  People then try to bolt on additional syntax to make it
work out, at which point the syntax is no longer obvious (and 
confuses at least half of the authors).  For me at least, the 
benefit gained is nowhere near the additional cost in complexity.

> What complications do hierarchical groups "seem" to impose?

Well, besides the page referencing problem, there's also the
issues of dealing with security in nested groups, which also
turns out to be non-trivial.  But we haven't ever gotten that
far because we haven't solved the referencing problem.

> >>>>Recipes should be able to determine whether an edit element is
> >>>>optional or required. Optional elements not mentioned on
> >>>>EditPage are left out, required elements are tacked on at the
> >>>>end.
> >>>
> >>>Or, all editing elements provided by recipes could be "required",
> >>>and an administrator can use DisableMarkup() and/or
> >>>ConditionalMarkup to selectively disable them.
> >>
> >>That's a different level of "require". [...]
> I didn't make myself clear
> enough and we're talking about slightly different things.

No, I fully understood what you're talking about -- I don't think
you followed my response.  We can make all editing elements "required",
which means that they have to appear somewhere in the markup text of
the EditForm or else PmWiki will automatically add them ("tacked on 
at the end").  So, in your example...

> Assume somebody edits the EditPage page, and removes the (:ef textarea:)
> item (say because he wanted to move it elsewhere, and forgot to actually
> insert it in the new place). [...]
> The *only* way to get out of this fix would be to manually edit
> wiki.d/Main.EditPage (not something I'd be looking for).

Okay, let's suppose someone removes the (:ef textarea:) from the form.
The next time an edit form is displayed, PmWiki sees that (:ef textarea:)
is missing from the markup and so it automatically adds it back in 
when displaying the form.  This handles your example.

Now then, what if there's a "required" element that the wiki 
administrator doesn't want to appear in the form?  Besides other 
methods, the administrator has at least two options here:
  1. The admin can disable the markup for the element in a
     configuration file, thus it won't ever display anything, even
     if automatically tacked on to the end by PmWiki.
  2. The admin can put the required element in the EditForm but disable
     it with conditional markup:
         (:if false:)(:ef previewbutton:)(:if:)
     Here, the required element is still in the markup text of the
     EditForm (so PmWiki won't add it), but it's in conditional markup
     so it won't be displayed, which is what the admin wanted.

Now then, the only bad possibility that can result is if the administrator
conditionally excludes an element such as (:ef textarea:) or 
(:ef savebutton:) in the EditForm markup, i.e., by writing something
like (:if false:)(:ef textarea:)(:if:).  But I think the likelihood
of that happening is extremely small, and as you mentioned there are 
other mechanisms for getting around this problem besides having 
to manually edit the EditForm file.  (1. Rename the EditForm file.  
2. Delete the EditForm file.  3.  Use config.php to specify a different
EditForm.  4. Copy the good EditForm from wikilib.d. ...)

Beyond that, using conditional markup here adds many other 
possibilities (such as displaying certain buttons based on
authorization or identity) that go far beyond a simple
"optional/required" flag, as well as being totally consistent with the
mechanisms being proposed elsewhere in PmWiki.  And by making all
edit form markups "required", any new edit form features supplied by 
new recipes will automatically appear in the edit form unless/until 
explicitly disabled somehow by the administrator.

Pm



More information about the pmwiki-users mailing list