[pmwiki-users] Edit page extensions

Joachim Durchholz jo at durchholz.org
Mon Apr 25 13:32:47 CDT 2005


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.

Hmm... this strategy obviously doesn't work with group-specific 
configuration. (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.)

> 2.  It's pretty clear that by default EditPage would need to be locked
> against all edits except by the administrator.

Agreed.

> 3.  What happens if EditPage doesn't exist?  Some admins remove
> (or de-activate) the pages that come distributed with PmWiki,
> so we'd want to handle that situation somewhat gracefully.  (Perhaps
> it just falls out of the "required elements tacked on at the end"
> condition.)

It should. (Modulo another existence check, of course.)

> 4.  Perhaps it should be called "EditForm" or "EditPageForm"?
> Or, for symmetry with the variables it affects most directly,
> perhaps PageEditForm?

No better ideas on my side for that.

>>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.  This way including a recipe would
> automatically cause its feature(s) to be displayed in the edit page
> form, and authors could reposition or disable the features by modifying
> the EditForm.

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.

>> For this reason, recipes must be able to call out to a separate
>> page.
> 
> I might save this for a later extension-- getting functions to be able
> to modify the input forms is just a bit tricky.  Small steps might be
> better here.
> 
>>The PmWiki core should name all the edit page elements that it uses, so 
>>that the admin can leave out or replace what he wants to customise. The 
>>liste of core edit page elements that I see is (*very* tentative names):
>>  title, guibuttons, textedit*,
>>  author, minoredit, savebutton*, previewbutton, resetbutton, tips
>>The items with a star are those that should be made required.
> 
> 
> - I'm not sure what you mean by "title" here,  and (:title:) is already
>   taken anyway.

The "Editing $Group.$Title" string.

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

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

> - We need a "preview" element.

Right, I overlooked that.

> - It might be a good idea to name all of these such that they're
>   less likely to conflict with other non-edit-page markups.  I.e.,
>   (:edit_guibuttons:), (:edit_textarea:), (:edit_author:), etc.

[Already overridden in next post.]

> - My list:  edit_savebutton, edit_textarea, edit_guibuttons,
>   edit_previewbutton, edit_cancelbutton, edit_author, edit_summary,
>   edit_minorsave, edit_preview, edit_messages.

I haven't checked, assuming the list is OK. (If not, it would be easy to 
fix anyway.)

> - For all of these, we'd need to be sure to have support for
>   accesskey shortcuts.  I'm still working out the details of what
>   I want to do there, although I'm fairly sure it's going to be
>   configurable at the individual user level.

Aaargh... please, make it a non-accesskey distribution by default if you 
really want to indulge in access keys! Or make it a matter of recipes.

Web pages that modify the way the browser interacts with me are a 
horrible thing. I don't want to relearn my access keys for every site 
that I visit, and most users don't want that either. I know many people 
want them, but I think it's unwise to implement that.

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

>>The framework would be good for creating other kinds of pages beyond 
>>those for editing. Applications that I can see are:
>>* In general, pages that are built from a wiki page.
> 
> If this is the case, we probably ought to develop and standardize a
> markup for all forms and avoid specialized edit-page markups, similar
> to WikiForms or the FormGuideSystem.

Just my thinking.

Regards,
Jo



More information about the pmwiki-users mailing list