On 1/8/07, marc <[EMAIL PROTECTED]> 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. Of course, some of the other tools in zap are rather useful... > 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... 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, 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? > I like the idea of the profile page being used for member-related data > that is stored as PTVs. Actually, this was the main reason I started developing zap, specifically to do this, because of several things I could do in Drupal but not in PmWiki. For example, zap allows members to register and collect any kind of data you desire, and then PmWiki can customize what individuals see on any given page using conditionals and the data stored in their profile. It works sweet! It's also easy for members to update their preferences. Though I haven't tried it yet, there's no reason you couldn't even allow members to select their own custom skin preference say from some pull down menu, and have it switch automatically whenever they log in! Or in the case above, at the click of a link... Cheers, Dan _______________________________________________ pmwiki-devel mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
