[pmwiki-users] Edit page extensions

[Joachim Durchholz]

Patrick R. Michaud wrote:

> 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?  :-)

Actually I'm not sure that using a group is a good idea.

> 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?),

Um, "configuration of this site" and "PmWiki documentation". Actually
it's already taken for the latter use, and I wouldn't want to change that...

Maybe PmWikiConfig (no language named "Config" out there *gg*). Though
that's far too long to suit my taste...

> 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.

> 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.

Keeping ears pricked for that...

>> 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.
> 
Well, yes, but any avoid-namespace-collision strategy is going to fail.
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).

I don't have a good strategy for that. I have seen lots of workarounds,
some better, some worse, but none has the smell of being the Right Thing.

I've also been thinking about using some special character as prefix for
special pages. Say, the bars would be configured in the wiki pages
-TopBar, -LeftBar, -RightBar, and -BottomBar, so if somebody sets up a
group with descriptions of places where you can eat and drink, he'll be
able to set up page Drinking/BottomBar for the latest "in" place called
"Bottom Bar", and still have a bottom bar in the Drinking group.

I don't particularly like that special character prefix either. (It
would solve issues with users accidentally creating a page with a name
that has a special meaning for PmWiki though.)

>> (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

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.)
What's the problems with page referencing?
What complications do hierarchical groups "seem" to impose?

>>>> 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.

I wasn't thinking about DisableMarkup. If something is done in PHP, it
can be undone in PHP, so no serious trouble here.

> 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.

Agreed. Though I wouldn't consider a boolean flag per edit control
"substantial".

> Especially if we offer the possibility of multiple save buttons with 
> slightly different interpretations.

Now this I don't understand, which means I didn't make myself clear
enough and we're talking about slightly different things.

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). He'll be able to save the new version of
the EditPage all right, but when he opens up another page for editing,
he will have no text input field. When he notices his mistake and wants
to edit EditPage and reinsert the (:ef textarea:) markup, he will
*still* have no text input field, so he can't undo his change anymore!
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).

Hmm... or he could rename wiki.d/Main.EditPage so that
wikilib.d/Main.EditPage is used again. Now *that* sounds good enough for me.

>>> - 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.

Agreed.

>>> - 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.

Only if he's HTML-savvy.
(Agreeing otherwise.)

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

OK.

Regards,
Jo