[pmwiki-users] Setting and getting cookies in PmWiki

Bellave Jayaram bellavejayaram at cox.net
Sat Mar 25 18:00:17 CST 2006

	Thanks, I will try the hidden field idea but don't I still need the
(?name) markup to be able to code my generating function (in other words,
the "checkout")? I am still a little confused because of all these multiple
pages/forms and hidden fields and how it might all work but....

	Alternatively, since the (?name) markup is not available, and to
avoid multiple pages, should I consider including each of the pages with a
form into one big page (could be of the order of 1000 lines with about 200
checkboxes) so then it becomes easy to process just one form? 

The thing is that not all these pages with checkboxes need to be submitted
for the generating function - in other words, some pages may not have even
one checkbox checked. So, the multiple pages provides the option of not
visiting those pages, if one doesn't care to and still be able to run the
generating function. I will have to wait and see on the usability reactions
from users after I do it one way, I guess.


-----Original Message-----
From: pmwiki-users-bounces at pmichaud.com
[mailto:pmwiki-users-bounces at pmichaud.com] On Behalf Of Joachim Durchholz
Sent: Saturday, March 25, 2006 1:54 PM
To: pmwiki-users at pmichaud.com
Subject: Re: [pmwiki-users] Setting and getting cookies in PmWiki

Bellave Jayaram schrieb:
> Jo,
> 	Thanks a lot. This helps a great deal. After reading the caveats, I
> have one question - what can I do in PHP to create a unique code (maybe 3
> 4 digits) for each string I want to store in the list_of_strings and then
> decode it back to the string in the generating function? I don't yet know
> how large my session data could get but if it does become large, this
> be one way to reduce it, wouldn't it?

Yes, but I wouldn't worry unless the data becomes really large.

> Alternatively, if I want to avoid $_SESSION completely, I am wondering if
> could use the (?name) markup that Pm said he might provide as a recipe in
> the 'getting form variables' thread - (provided it can be used on more
> one form submit and not just the last submit).

Hmm... that would mean putting everything into form data (using hidden 
fields), in the form of
   <input type="hidden" name="whatever" data="..." />
HTML fields.

On the plus side:
1) Session storage will be kept to a minimum.
2) The server isn't responsible for storing the data. Session data 
typically "dies" after half an hour of inactivity, while data in a form 
will live even if the user is away for lunch.

On the minus side:
3) The data will be sent across the network. If there's so much data 
that session storage becomes a problem, then it's also enough data that 
network transmission will take noticeably longer (unless server and 
browser are on the same local network, in which case this point doesn't 
really matter).
4) The user will be able to inspect and even modify that data. Don't 
trust the data you'll be getting back, particularly not for things 
involving money or a service for which you give monetary guarantees.
5) You have to HTML-encode the data before placing it in the <input 
type="hidden".../> field, and HTML-decode it when retrieving it from 
$_REQUEST. This encoding and decoding may have subtle bugs (particularly 
if your data is binary, or may contain umlauts or other "funny 
characters"), and it also takes CPU time (most Internet servers are 
either network-constrained or CPU-constrained, disk space is far less of 
a concern).


pmwiki-users mailing list
pmwiki-users at pmichaud.com

More information about the pmwiki-users mailing list