Another CGI question. Keeping an array over more than one Webpage.

[Malte Brill]

Hi all,

thanks for responding.

Terry Vogelaar wrote:

>Remember that the engine quits as soon as the file is processed. So
>while you read the results, the engine is not running anymore. When you
>save data to an array, it has to be a custom property as an array and
>you have to save the stack to keep the data. That data will remain
>there available for all users until it is erased or overwritten.

That´s what I suspected. And explains why I failed with my experiments.

Jan Schenkel wrote:
>At the risk of getting slammed by the anti-cookie
>lobby : you could always store session variables in
>cookies.
>You can serialise your array and encrypt that data as
>well if you want to, and these cookies can be
>automatically deleted when the user quits his browser,
>or you can have them expire at a certain time, etc.

That is what I´m dreaming being able to do. But I must admit it is a bit
over my head at the moment.

I´m trying to set up 4 Webpages.

fruit.html
meat.html
perishable_food.html
vegetables.html

Each Html file has a set of forms. A desrciption of an item, a field to type
a numerical value in. The CGI should be able to add the values submitted by
the user as long as his session takes and allow to add other items. If the
user hits a "Now what´s for dinner" button the CGI should return something
like this:

You got 3 bananas, 1 peach, 1 broccoli, 5 potatoes, 1 egg, 1 cup of cream
and a steak. You can do a steak with broccoli and au gratin potatoes. You
can also have a fruit salad for dessert if you are willing to spend about
1.5 hours in the kitchen.

or if there is no food:

You got no food at all. Go shopping you lazy bag.
 
(Guess what I´ve been toled until now...)

JBV wrote:

> Nevertheless, I keep thinking that using cookies is a blatant
> demonstration of lazyness for a programer (nothing personal
> of course) 

Or they don´t know any better yet. ;-)

>and that there are more elegant solutions.

I´m eager to learn these. But what is the most important for me is to find
out what I could be able doing using Rev as CGI.

> Furthermore, I know many end users who are virulent anti-
> cookies as well, who disable systematically the cookie option
> of their browser, and who get really irritated when a webpage
> refuses to display because they turned off the cookie option and
> who swear god they'll never visit that website again...

That´s a serious concern. I am aware that users can turn off cookies. I know
quite a few Users that disable cookies. But they would be willing to accept
cookies if they are really neccesary.
For my experiments it is not a serious concern, as it is only a brainteaser
for me.

Richard Gaskin wrote:

>I'm no fan of cookie abuse, and I looooooove that Mozilla let's me
>approve them individually (I always nix the ones from evil ad companies
>that track you all over the Web).

I hope many Users think that way. I guess if one promisses not to bomb the
user with popup adds they might be willing to accept cookies.

>But how else does one maintain state information, esp. between sessions?

I would also love to know that.

jbv wrote:
> you can use temp files on your server, or hidden flds on your
> successive webpages with the post cmd.

Pierre Sahore wrote:
>The second way you describe, JB, (the use of "<hidden>...</hidden>"
>tags in the posted Form) is the first i would recommand if the cgi/app
>need to interact with lots of clients in concurrent access mode. If
>needed, this way lets us crypt - encode/decode - the hidden tags
>contents from the server-side cgi/app, if we wants to preserve those
>datas from beeing viewed, on the client side, by reading the form
>source code.
So I would need to post the whole data I need on all 4 Webpages in hidden
Tags? Would I need to call 2 CGIs to avoid refresh errors? The first to set
all values to zero and the second to add values from there? All HTML is
returned by the CGI created on the fly, no static HTML files? Please excuse
my dumb questions. I guess I´m thinking too static (webpages are build in a
texteditor...) here.


Best,

Malte