[pmwiki-users] Input recipe

Joachim Durchholz jo at durchholz.org
Fri Jun 24 15:04:08 CDT 2005


Martin Fick wrote:

>>I do think that in most cases, it's just the admin who's supposed to 
>>edit a form page, though there are exceptions:
> 
> ** I think that is a uneccessary role assignment to admins
>    only.  It's probably a big reason why so many UIs suck! 
>    Only the 'blessed' few (programmers or administrators)
>    can adjust and modify them.

Ahem... only those "blessed few" can install scripts that process the 
input form, so there's a limitation anyway.

I do agree that a PmWiki admin could install a script and allow people 
to set up their own forms to address that script. In fact that's an 
excellent and very wiki-ish idea.
I'm not sure how to best address this. There's a design tension here - 
I'm not yet 100% sure that everybody should be allowed to insert a form 
on a page. (He might fake a login page that's exactly like PmWiki's 
standard login, but sends the data to his server first. That way he'll 
get user names and passwords. Installing the fake page so that an 
unsuspecting user will see it could be a challenge, but it's already 
nearer to a phishing attack than I'd like.)

>>> does not need to understand bulleted lists to edit a trail.
>> 
>> Not a good idea IMHO. One of the things that makes wiki trails
>> useful is that you can have trail info and running commentary
>> intermixed; "formalising" that into a form page would destroy that
>> functionality.
> 
> I'm not sure why you think it would be lost, the original page wold
> still exist but a additional form page would help users who don't
> even know that you are running a wiki.  But wait, that's the wrong
> answer anyway; if the form lost important functionality, the users
> can add it back in themselves by improving the form!

The form isn't the same as the trail page itself. The form would have to 
start a script that edits the trail page.

>   I'm not sure I'm following this, what I meant was: that
> there could be some simple generic backends that: knew how
> do edit a DB, knew how to edit templated wiki pages and
> that knew how to email forms to people.
> 
>   I agree that pmwiki is flexible enough for me to define
> my own markup, I'm just not sure I'm smart enough :(.

If you're a software developer, it should be dead simple. Look up the 
documentation for the Markup() function (see 
http://www.pmwiki.org/wiki/PmWiki/CustomMarkup).

> I guess that's why I'm trying so hard to get others on board. If
> anyone else thinks it's a decent idea I will start a wiki page where
> we could work it out, but I'm not sure anyone else is.  I am probably
> just deluding myself. :) Anyone, anyone...??

Hey, it *is* interesting. I'm not too much into that hard split myself. 
It's just that it's easier to get it to work with that mental model.


Let me sum up my perspective:

1) I'm rather dubious about adding yet another irregular syntax, be it 
for input forms or anything else. With every syntax we force yet another 
set of [=...=] brackets on those who happen to type something that's 
interpreted by the new markup. The special syntaxes for input fields and 
forms, cute as they may be, don't meet my approval (for what that's 
worth, it's Pm who decides *g*).
The next argument is that form syntax is rare. Things like italics and 
headers are used all the time, so doing special syntax for these is 
warranted. Even if form pages spring up all over the world, there will 
be explanatory and commentary pages for them, and I'd be somewhat 
surprised if form markup ever gained more than 1% of total markup uses 
in PmWiki installations. In such a case, special syntax isn't warranted; 
stick with regular (:...:) syntax for these.
That means I'm casting a strong vote against special syntaxes.

2) I'm all for opening up form input markup for visitors. However, there 
are some security implications involved, particularly with the URLs that 
visitors are allowed to use (and maybe beyond that). It might even make 
sense to give visitors some scripting capabilities to process the input 
data, but that opens up yet another set of security issues.
In other words, I think we're in violent agreement that it's worthy, but 
I wouldn't want to do that until I have done a quite thorough risk 
analysis. And I'm not feeling up to that task until I have seen the 
recipe in action (and maybe even then I'd prefer that somebody else does 
the risk analysis - finding the holes in one's own concepts is always 
difficult).

Hope that clears things up a little :-)

Regards,
Jo



More information about the pmwiki-users mailing list