[pmwiki-users] Edit page extensions
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.
> 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"
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
> 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
> - 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.
More information about the pmwiki-users