[pmwiki-users] Input recipe

Joachim Durchholz jo at durchholz.org
Fri Jun 24 09:27:03 CDT 2005


Patrick R. Michaud wrote:

> On Fri, Jun 24, 2005 at 01:36:37PM +0200, Joachim Durchholz wrote:
> 
>> 1) Control and attribute terminology.
>> That's something that warrants a conscious decision, but the 
>> architecture allows changing it without trouble, so this isn't a
>> serious problem.
> 
> The forms.php recipe makes it very easy to define custom controls,
> custom attributes is still a bit tricky.

It's more about adapting the terminology one way or the other. It should 
be easy to switch from the current terminology (consistent with HTML) to 
a terminology that's consistent with itself, simply by exchanging the 
relevant strings.

>> 2) Background data threading.
>> There's no provision for that in the Forms recipe yet, so it's easy
>> to  add.
> 
> While the forms markup is likely to make it into the distribution, I
> don't know if background data threading needs to go in the
> distribution. I'll have to take a look at it.

One of the reasons to add session data was mail address obfuscation - 
actually Input is a spin-off of trying to do a better mail address 
obfuscator :-)

Mail obfuscation using session data would work as follows:
Mail addresses are links to a mailform that allow sending mail to that 
address.
The mailform's submit button sends the mail to the address given on the 
first page.
The mail address is handed from one page to the next via a session 
variable. The effect is that if you put a mail address on a PmWiki page, 
you become reachable from that PmWiki installation, but since the 
address is never sent to the user's browser, spammers can't harvest it.

Session support could be made part of the mailprotect recipe, but I 
think it's generally useful enough to be either a recipe of its own 
right or part of the form handling. For example, values in $_SESSION 
don't need to be serialised, HTML escaped, and back as would be needed 
for hidden input fields; besides, hidden HTML data is strongly 
restricted size-wise (typical limits are "4K maximum request size", and 
the hidden input fields count against that limit when the browser sends 
it back). I'm not sure about size limits for session variables - that 
seems to depend on the session handler (file storage or shared memory), 
but either way, I'd expect far more generous limits :-)

Regards,
Jo



More information about the pmwiki-users mailing list