[pmwiki-users] Input recipe

Martin Fick 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
being.
  


> >  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 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 
> difficult).
> 
> Hope that clears things up a little :-)

  I think you've made some solid points. :)

  Thanks,

  -Martin





More information about the pmwiki-users mailing list