[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