[pmwiki-users] AddDeleteLine version 2.0beta2

[The Editor]

Just a note Nils, that this is the whole basis for how FAST Data
works.  It takes all the form fields, processes them one by one, and
depending on the field->value combination does all kinds of actions.

In fact, it can run one string of commands (say send an email
constructed from various fields), then run a bunch of conditionals and
change any POST fields it wants, and then run a whole nother string of
commands, say set up a confirmation page somewhere, and then do some
more.  In fact, I'm not sure where the theoretical limit for this kind
of programming is, but I have some quite complex systems going on FAST
Data that don't really take a *whole* lot of code in the recipe.

Combined with the conditionals in PmWiki for example I can set up a
default form.  When one of several buttons is clicked, the page
reloads, but is passed a specific GET variable by FAST Data.  That GET
variable is retrieved as a page variable by FAST Data, and then used
in conditionals to trigger completely different forms which do their
own thing.

So for example, in my instant messaging system, one group footer has a
form for visitors to leave a message, a display for members to see
their messages, and a form for members to update their greeting and/or
delete their messages. PmWiki retrieves the proper form using it's
conditionals.

So you cut and paste the code into a group footer, create the pages
virtually using AuthId for the page Name, and bingo--an instant
messaging system.  It's really cool.

My question is, what exactly did you do to ADL Martin?  I couldn't
follow your explanations of the improvements you are making?  :)  And
I'm still curious how you pass in multiple radio boxes.  I have a need
for that for a quiz setup I'm running that required to select more
than one option.  Any info anywhere I could read up on?  Or some
sample code you could show me?

Cheers,
Caveman

PS.  Oh, Nils, and as for Target fields, why not just pass the
NextPage variable into the form through a hidden field also?  I set
both the NextPage and DataPage variables that way and have a nifty
little FixPage function that introduces lots of fun shortcuts.



On 9/24/06, Nils Knappmeier <nk at knappi.org> wrote:

> I don't like the idea of just adding a hidden field in the form for
> three reasons:
>
> 1) It seems to be an unclean way of doing things, overriding
> one field entry with another one. I don't know if it is standardized,
> that every browser sends the fields on the post-request in the exact
> order in which they occur in the HTML page. I don't know if PHP
> always takes the last value of the field. Seems to be something that
> might work, but may also fail.
> This was actually the reason, why I added the "target=" option in the
> first place.
>
> 2) This does not work it you use CleanUrls. At least that's
> what I figure. I you look into the target URLs of the e.g.
> the edit form on pmwiki.org, you'll see, that the pagename
> is also part of the target-Atribute of the <form ...> element.
>
> I'd like to be corrected, if I'm wrong, but this seems to be
> essential for $_POST-ing form data to a page. I can't say I fully
> understand why, but when I tried to ...
>
> Well, that's weird, it seems to work... Mhm, I don't understand...
> It didn't work, when the target was set to $ScriptUrl...
>
>
> 3) In PmWiki it is common that a link to [[SomePage]] leads to
> CurrentGroup.SomePage. If a form allows you to enter a page name
> (such as the (:newpagebox:) for example, than this should have the
> same behavior in my oppinion.
>
> Alright, it seems to work, so there is no urgent need to do anything
> about it.
>
> I am impressed, anyhow.
>
> Nils
>
>
>
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>
>
>