[pmwiki-devel] Question about Forms & Actions
editor at fast.st
Mon Dec 11 11:24:04 CST 2006
On 12/11/06, Ben Stallings <Ben at interdependentweb.com> wrote:
> Hans wrote, quoting me:
> >> return "(:input form
> >> > action=$ScriptUrl?n=$pagename$u$o:)\n(:input
> >> > hidden action zap:)\n(:input hidden ZAPkey $x:)\n";
> > I would probably write (but it may be all the same):
> > return "(:input form $ScriptUrl post:)
> > (:input hidden n $pagename$u$o:)
> > (:input hidden action zap:)
> > (:input hidden ZAPkey $x:)";
> Beyond the line breaks, it's not the same, because $ScriptUrl only gets
> you the URL of pmwiki.php, while $ScriptUrl?n=$pagename gets you the URL
> of the page. Maybe there's a more elegant way to get the URL of the
> page, but $ScriptUrl is not sufficient.
> Thanks for specifying "post" in there, Hans -- can't take for granted
> that all browsers will assume a form is method="post". But I believe
> that's included in the $u variable.
> Caveman wrote,
> > (Ben, did you check this? I thought ZAP automatically stripped off
> > any GET values beyond the page name...)
> I'm sure it does, when ZAP runs, but when the form is submitted to a URL
> that includes ?action=edit, ZAP doesn't get a chance to run, because
> PmWiki sends the $_POST data to UpdatePage() instead. So to reiterate,
> what I'm saying is that the form needs to specify the URL explicitly so
> that the browser won't tack ?action=edit onto it.
> I realize I may be the only person who's ever tried putting ZAP in an
> EditForm, but once you see it in action, so to speak, you'll all want to
> do it. ;-)
> Caveman wrote,
> > Thanks Hans, that helps. So theoretically if I implemented Ben's
> > suggestion, making it possible to set an action parameter in the form
> > field, one could do both server side processing (say of a cgi script)
> > simultaneously with whatever zap actions are called.
> I believe it's an either/or proposition: either you send the data to a
> URL that's processed by PmWiki, or to another script. But yes, you
> could use a ZAP form to retrieve data and submit it to an external
> script, which could be very useful for data-processing tasks that are so
> specialized they don't justify writing a recipe.
> > Anyone know how this might affect the HandleBrowse and/or Redirect
> > code in ZAP? That is, are Pm's actions done before the form action?
> > And if so, would the server action override ZAP's closing actions or
> > would the server be ignored?
> Not sure we're using the same terminology yet... again, we've got two
> different things called "action" here: one is in the HTML form tag and
> determines the URL the form is submitted to; the other is handled by
> PmWiki. The first one is much more fundamental than the second, since
> it determines whether ZAP runs at all. Once you've got your data into a
> page that runs ZAP, then you can worry about HandleBrowse and Redirect.
> Don't know if that's the answer you were looking for. --Ben S.
OK Ben, I think I've got this figured out and am ready to make the
change just as you suggested. (Sorry I'm a bit slow). I'm making
quite a few minor fixes to ZAP and hope to release it later today.
But just to verify I got this right...
1) The form action tells the browser where to send the form post,
normally to PmWiki, but it could be to a cgi script, or wherever.
That's why you can use a regular PmWiki form to control where the
browser goes on submission... (like nextpage in ZAP). The hidden
action field in the form tells PmWiki to call the corresponding
function, in this case the zap engine. The form action is a html
feature, the field action is a pmwiki feature.
2) If I wanted to do some external cgi scripting, (which is NOT what
you are talking about doing), I could change the form action parameter
to the url of that script, but that recipe would have to then send the
$_POST values back to PmWiki with the right url (including action=zap)
in order for the zap engine to be called afterwards. So it might be
worth making this configurable.
3) In your situation, you need to explicitly set the form action,
because, you are doing it in the edit form, and PmWiki automatically
calls the current url which has action=edit. Which means field
action=zap is ignored and the zap engine doesn't get called. If we
set it to the same url, but without the action=edit, then PmWiki will
pick up the zap action field and work as desired. Do I have the gist
of all this?
To make it configurable, how about setting a SDV value for
ZAPformaction = to "action=$ScriptUrl?n=$pagename" and then insert
this into the form markup. This way, an admin could overwrite it if
desired in a local config file?
Let me know if I'm more or less on track and I'll try and work out the
code, (or you could supply it to make sure it works for what you
need). Thanks for the suggestion and explanation. Very happy to make
zap work better if possible.
PS. Could you explain why you are using ZAP in an edit field?
Interesting, but no clue why you are using it this way... Quite
More information about the pmwiki-devel