[pmwiki-users] Input recipe
fick at fgm.com
Fri Jun 24 15:35:14 CDT 2005
> >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.
Yes, but imagine a form CGI that was a generic Trail
editor and allowed the specific trail to be passed in
as an argument.
Of course, this is independent of what the syntax ends up
> > 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
I get that part. the part that's hard is what you elude
to below: how to make it not interfere?
> 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.
I agree with this, you've convinced me at least of the
difficulty in defining an acceptable syntax. I do think it
will be too complicated. Even if the cases for it are
numerous (as I believe they are), I agree that it would be
a small percentage of all wiki pages. Therefore it might
make a nice recepie, but certainly not a main pmwiki
thing. In the mean time, simply having a clean common
pmwiki form is usefull to me. :)
> 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
> Hope that clears things up a little :-)
I think you've made some solid points. :)
More information about the pmwiki-users