[pmwiki-devel] ZAP configuration fields (was: PmWiki request)

The Editor editor at fast.st
Tue Dec 12 12:03:01 CST 2006


On 12/12/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Tue, Dec 12, 2006 at 10:31:25AM -0600, Ben Stallings wrote:
> > Hans wrote,
> > > You know, seeing conditionals inside (:input :) markup makes me cringe.
> > > I know you try to create shorter syntax for ZAP.
> > > But you go against what people learned and know in PmWiki.
> > > You seem to have hijacked PmWiki's (:input:) markup
> > > and made something quite different out of it.
> > >
> > > To me any (:input ... :) should be only used to create form elements.
> > > Conditions as to when a form element shall be added to HTML output
> > > should stay out of the markup, as it is already possible with
> > > (:if ... :) markup. Manipulating any page variable used inside (:input
> > > :) should also stay outside of the markup.
> >
> > It's easy to misunderstand what ZAP does with these tags... I did at
> > first, as well.  All the (:input hidden :) tags in a ZAP form produce
> > actual hidden fields, via the core forms.php script, that are then
> > submitted with the form.  The conditionals Caveman is proposing are not
> > for use when the form is displayed, they are for use when the form has
> > already been submitted.  ...
>
> FWIW, even if ZAP uses hidden form fields to do its thing, it
> still may make more sense to create a special directive for it
> rather than try to fit everything into (:input hidden:).  For
> example
>
>    (:zapcheck ifexists pagename "warn:page exists":)
>
> can still produce a hidden input field in the form, but it can
> also do any reformatting -- e.g., it could output
>
>  <input type='hidden' name='zap_ifexists' value='pagename|warn:page exists' />
>
> and thereby avoid input control name conflicts and any special
> syntax needed to communicate the control.

One of my goals was to not have to develop my own form markups
wherever possible, and I only did a couple to address a lack in the
old forms script.  In fact, my plan all along has been to delete zap's
few forms markups as soon as the new ones came out.  Others could
develop their own, but I hesitate to do so, when yours work so well.

And while I do see the point of being able to automatically rename
form fields, anything along these lines is going to require renaming
all the features in zap, and break every existing zap form in
existence.  I mean, every line of every form...  That's a pretty big
break...

> > I've been lobbying Caveman off-list to move all of his configuration
> > variables out of hidden input fields and into page text variables,
> > because as input fields they potentially conflict with other field
> > names.

Actually I think there might be a different solution without breaking
zap forms.  See below...

> The above approach solves that particular problem.  :-)

Actually it only solves it in the sense it translates feature names
from nextpage to zapnextpage automatically.  But that solution breaks
everything else. Granted, zap is still new, has relatively few users,
and if we got to do this, it's better to do it now--but I probably
have between 50 and 100 forms on my zapsite alone.  And some are quite
long and complex.  I dread the thought...

> > So in the syntax I'm waving in Caveman's direction, the tag
> > (:input hidden ifexists "parameter|action":)
> > would simply become
> > (:ifexists: "parameter|action":)
> > This would have the added benefit of removing the configuration
> > variables from the HTML code where people can tamper with them.

If this markup just converts it to another input form it won't solve
the problem, but if it saves the hidden value it to a page variable it
might.  However I have a different solution that may work.  Maybe some
of you could offer feedback on it.

1.) Continue to have input forms as normal with the existing names.
2.) Have a (:lock Sx:) markup, or perhaps (:zaplock $x:) that would
allow you to save any field=value pairs you want as a session variable
array. It would return no markup to the html.
3.) When the form is submitted, the zaparray session variable is
retrieved, and any fields in the form are appended to it, and then
this combined zaparray is processed by zap rather than the post array.

ZAP essentially does this already, except it takes the zap array and
adds it back into the post array, rather than the other way around.
Also the lockpattern syntax is not very clear or intuitive to most
users, so I should change it.

Ex:

(:zapform:)
(:input text Phone :)
(:input text Email :)
(:zaplock datapage Group.Page:)
(:zaplock savedata Phone,Email:)
etc.
(:input submit:)
(:zapend:)

In this example, Phone and Email would be regular input fields that
show up for user input, datapage and savedata tells where and what
data to save.  These latter two would be set as a session variable as
$ZAParray['datapage'] and $ZAParray['savedata'].

When the submit button is clicked, the zap engine is called and Phone
and Email are added to $ZAParray, then $ZAParray is processed instead
of POST as usual.

This solves some of Ben's problem without breaking everything in ZAP
while strengthening security and making the ZAP lockpattern easier to
understand and use.  What do you all think?

Cheers,
Dan



More information about the pmwiki-devel mailing list