[pmwiki-users] Edit page extensions

[Patrick R. Michaud]

On Mon, Apr 25, 2005 at 08:32:47PM +0200, Joachim Durchholz wrote:
> Patrick R. Michaud wrote:
> 
> >On Mon, Apr 25, 2005 at 02:19:29PM +0200, Joachim Durchholz wrote:
> >
> >1.  Where should EditPage live?  I'm guessing it should live as 
> >Main.EditPage, although this could obviously be configurable.
> 
> Since PmWiki is going to place more and more configuration data on wiki 
> pages, I suggest creating a group for such pages. This makes it easier 
> to filter them out from page lists and searches, for example, and also 
> gives the administrator a common place to look for configuration data.

If you're going to suggest a group, perhaps you could also suggest an
appropriate name for it?  :-)

Me, I kind of like Christian's "Site" group, but I'm adverse to
predefining group names that an author/admin might want to use for
some other purpose.  "PmWiki" is probably pretty safe (how many different
meanings of "PmWiki" can there be?), and "Main" is a good choice because 
almost nobody wants to use it for anything else.  :-)  Because a site
admin might wish to use them for other purposes, I think things like
"Site", "Admin", "Config", etc. might not be good choices.

More on this next post.

> Hmm... this strategy obviously doesn't work with group-specific 
> configuration. 

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.

> (Is there a write-up of the pros and cons of hierarchical 
> groups somewhere? I don't want to rehash the old discussion, but I'd be 
> forced to unless I can reread the old arguments.)

http://www.pmwiki.org/wiki/PmWiki/HierarchicalGroups

> >>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". Some edit page elements (namely 
> the text input field and the save button) must absolutely be present, 
> otherwise administrators can paint themselves into a corner by 
> (accidentally) disabling them.

Presumably an admin who disables the "save" button using DisableMarkup()
in a php configuration file can fix it.  Someone who accidentally
disables the "save" button using conditional markup may be in a slightly
bigger fix, but I consider this to be so rare that it's totally not 
worth the substantial programming effort that would be needed to avoid it.
Especially if we offer the possibility of multiple save buttons with
slightly different interpretations.

> >- I'm not sure what you mean by "title" here,  and (:title:) is already
> >  taken anyway.
> 
> The "Editing $Group.$Title" string.

This properly belongs in the text of the EditForm itself, not as a
separate element.

> >- I'd prefer "textarea" over "textedit".
> 
> "textedit" is better IMHO. "textarea" doesn't mention that the text is 
> editable (there could be a text area that displays read-only text). (I 
> find the HTML tag <textarea...> is a misnomer, and wouldn't want to 
> continue that in PmWiki.)

Regardless of whether HTML's <textarea> is a misnomer, that *is* what
it is named.  Often reusing an existing name, even a misnomer, is much
better than introducing a slightly different one and then having to
explain the difference.  It also helps if someone is searching for
documentation on the <textarea> element in PmWiki's edit page.

> >- We probably don't need a "tips" element, since that markup can be 
> >  directly part of EditForm (or via (:include PmWiki.EditQuickReference:)).
> 
> It's still an element that somebody might want to disable.
> 
> Of course, if the EditPage (whatever we name it) is a wikipage, such 
> constant text can be made part of the wiki page itself or (:include:)d.

This was my exact point.

> [...rant about accesskeys...]
> (That doesn't mean that access keys shouldn't be implemented by PmWiki. 
> It's just that they shouldn't be encouraged, or on by default.)

I refuse to discourage them, or to try to second guess site's needs
here.  But the default will probably have them turned off, with a
simple switch or string to enable them.  It's likely they will be
implemented as part of the XLPage() interface, although I haven't
figured out how to do access keys in action lists defined by a wikipage
yet.

Pm