[pmwiki-devel] set up PagetextVariables from recipe ?

[marc]

The Editor said...
> On 1/8/07, marc <gmane at auxbuss.com> wrote:
> > > As for your request though, of making a clickable link that would
> > > reset a preference "onclick", the problem would be using the link to
> > > trigger a from submission, and then passing the link value to the
> > > form. It could be done, but it might take some thinking.  For ex: you
> > > could pass the language value and return page as get variables to
> > > blank page with a form which simply retrieves those values, resets
> > > the text variable and then forwards back to the return page. Two trips
> > > to the server though.
> >
> > Presuming that we have PTV get and set functions - it's inevitable they
> > will come ;-) - then it's not really that hard.
> 
> Actually, that is what zap does already.  It has a lot of extra tools,
> but the code could be stripped down to a bare bones version that did
> little more, if desired.

Ah, if you have functions to set PTVs then I'll have to pilfer them ;-) 
It'd be good if you could release them as a separate recipe.
 
> > One simple method is to
> > use an action handler; so it behaves in a similar way to the
> > PageAction's menu. You could also route to a page with a local
> > customization script, if it suits - I do this kind of thing for
> > confirming changed email addresses and suchlike.
> 
> Can you explain how to do this?  The zap engine already operates on an
> action handler ($HandleActions['zap'] = 'ZAPengine';) and it no
> longer requires POST values to set parameters as they can
> alternatively be set using session variables (assuming no user input
> is required).  Are you saying I could just put a link to
> Group.Name?action=zap and it would call the engine using any session
> values passed to it?  What an interesting idea...

Session variables live on the server, so they don't get passed around 
unless you do it yourself. So, I'm not sure what you mean. If you are 
storing state information about Zap in session variables, then why not
create a Zap object and grab it, as required. I find it a lot easier to 
grab one session variable and reference the object than manage a set of 
session variables, especially when they are related. I do a similar 
thing with my member object. It's not necessary to instantiate it (from 
a session variable) on each trip, since the user might not be logged in. 
However, when it is instantiated it can be read, updated and saved, as 
necessary.

There's obviously more than one way to skin a cat, and I suspect folk 
either go the route of one handler and many actions (via input hidden) 
or many handlers. I prefer the latter for forms - unless the actions are 
closely related. And to avoid bogging down PmWiki, I tend to keep the 
handlers in local customization files where possible.

In the case of the OP, I think a dedicated action handler is a good way 
to do what he wants. I have a similar use with a currency selector.

> It might need a bit of minor tweaking to get the security features to
> allow this, but it shouldn't be too hard.  I suspect there might also
> be several other valuable uses.  For example, letting someone
> unsubscribe an email address by simply clicking a link

I do something like this this on a member's profile page. Basically, it 
just requires some markup to do something like:

  [[ {*$FullName}?action=ToggleMailingList | Toggle mailing list]]

(with some additional indication of state - a checkbox or whatever 
floats your boat) to call the action handler. or group. 

> or creating a
> link that takes someone to a forum post and automatically logs them
> in.  What a powerful idea.  Am I understanding you right, Marc?

Dunno. But it sounds like it.

-- 
Cheers,
Marc