Stupid setcookie() question...

On 21/2/05 9:25 pm, in article cvdjkc$c5e$1@ls219.htnet.hr, "CyberDog"
wrote:

  >> So cookies I thought.
 > Use sessions.

Ok. I had a good reason for NOT using sessions. Namely that we wanted the
form input to persist for up to an hour after they started filling it in,
not just until the browser was closed or the session destroyed.


 > you need to start every page with session_start() but if you add
 > header("Cache-control: private") just after that, when user hits back in
 > his browser, the form will be filled in (remain filled in)

Ta. Could you confirm that the behaviour that I am seeing with cookies is
normal? If it is then I'll just junk them, but it would very much suit this
project more if I could use them. Also it would be useful reference.
 >> Stay informed about: Stupid setcookie() question... 

Bonge Boo! wrote:

 > Ok. I had a good reason for NOT using sessions. Namely that we wanted the
 > form input to persist for up to an hour after they started filling it in,
 > not just until the browser was closed or the session destroyed.

Putting session_cache_expire(1) BEFORE session_start() makes it expire
after one minute.
 >> Stay informed about: Stupid setcookie() question... 

CyberDog wrote:


 > Putting session_cache_expire(1) BEFORE session_start() makes it expire
 > after one minute.


SORRY! For a minute I tought that you said you DON'T want it to last an
hour..


whell default id 180min, if you just use session_start()
 >> Stay informed about: Stupid setcookie() question... 

On 21/2/05 9:51 pm, in article cvdl51$f3c$1@ls219.htnet.hr, "CyberDog"
wrote:

  >> Ok. I had a good reason for NOT using sessions. Namely that we wanted the
  >> form input to persist for up to an hour after they started filling it in,
  >> not just until the browser was closed or the session destroyed.
 >
 > Putting session_cache_expire(1) BEFORE session_start() makes it expire
 > after one minute.

All well and good, but that function requires PHP 4.2 or later to be
installed on the web server. My live webserver has 4.1.2 installed.

And forgive the dumb question, but does not closing the browser qindow
destroy the session and hence the values?

Which is not what I want.

Sorry to be a pain, but its the answer about cookies that I want. I know I
can achieve the same things, but I have good reasons for wanting to do it
this way. If I can't fine. But I need to know why the cookie is doing what
it is doing, and if it a programming fault at my end or the correct
"behaviour"
 >> Stay informed about: Stupid setcookie() question... 

Bonge Boo! wrote:



 >
 >
   >>>Ok. I had a good reason for NOT using sessions. Namely that we wanted the
   >>>form input to persist for up to an hour after they started filling it in,
   >>>not just until the browser was closed or the session destroyed.
  >>
  >>Putting session_cache_expire(1) BEFORE session_start() makes it expire
  >>after one minute.
 >
 >
 > All well and good, but that function requires PHP 4.2 or later to be
 > installed on the web server. My live webserver has 4.1.2 installed.
 >
 > And forgive the dumb question, but does not closing the browser qindow
 > destroy the session and hence the values?
 >
 > Which is not what I want.
 >
 > Sorry to be a pain, but its the answer about cookies that I want. I know I
 > can achieve the same things, but I have good reasons for wanting to do it
 > this way. If I can't fine. But I need to know why the cookie is doing what
 > it is doing, and if it a programming fault at my end or the correct
 > "behaviour"
 >

No, closing the browser does not destroy it, only if you pass it on as
links (url .SID.).

Sure you can achieve the same thing. how about setting the cookie for
every form field on the page that the form posts to... and then reading
the same cookies in the page that holds the forim and displaying the
data as values in the html part: (value:<? echo $_COOKIE['field_one'];
?>) Now THAT's a pain

--
<a rel="nofollow" style='text-decoration: none;' href="http://www.omega17.net" target="_blank">www.omega17.net</a> <--- prvi hrvatski MMORTS
--
<a rel="nofollow" style='text-decoration: none;' href="http://www.cdnforum.com" target="_blank">www.cdnforum.com</a>
--
 >> Stay informed about: Stupid setcookie() question... 

I noticed that Message-ID: from
Bonge Boo! contained the following:

 >Sorry to be a pain, but its the answer about cookies that I want. I know I
 >can achieve the same things, but I have good reasons for wanting to do it
 >this way. If I can't fine. But I need to know why the cookie is doing what
 >it is doing, and if it a programming fault at my end or the correct
 >"behaviour"

Yep it's correct and it can do your head in unless you get the sequence
of events correct.

Remember, cookies are small amounts of data stored on the client
machine( I'm assuming you are familiar with the terms client and
server). Consider what happens.

The first time you call a php script you send an HTTP request from the
client to the server (by clicking a button on a form, following a link
etc). This request contains the cookie information if it is set. If no
cookie is set so the script cannot receive one. The script may then
respond and set or update a cookie. Any value taken from the cookie
will obviousl;y be the one originally stored, not the updated one.

Say you make another HTTP request. This one contains the value of the
cookie and the script can read it and respond to it. So the script is
always behind. However, the cookie has been set, and can be read later.

Take your code:

setcookie('instruction_type', $_POST['instruction_type'], time()+1800);
print "We set the cookie to: " .$_COOKIE['instruction_type'];

So as you have seen it is working as predicted. If you did:

setcookie('instruction_type', $_POST['instruction_type'], time()+1800);
print "If your system allows it,
we have set a cookie with the value of: " .$_POST['instruction_type'];

It would at least read correctly, but you can not be certain the cookie
is set because the cookie is stored on the client and the only way the
server can know that is when it receives another request.

What you can do is this: The first time the page is served it should
attempt to initialise a cookie. When the form is posted, the script
should check that cookie is set. If it's not give a warning that the
session will not be saved. If it is, everything is fine.

HTH.
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs <a rel="nofollow" style='text-decoration: none;' href="http://www.ckdog.co.uk/rfdmaker/" target="_blank">http://www.ckdog.co.uk/rfdmaker/</a>
 >> Stay informed about: Stupid setcookie() question... 

On 21/2/05 10:30 pm, in article cvdnf2$jsk$1@ls219.htnet.hr, "CyberDog"
wrote:

  >> Sorry to be a pain, but its the answer about cookies that I want. I know I
  >> can achieve the same things, but I have good reasons for wanting to do it
  >> this way. If I can't fine. But I need to know why the cookie is doing what
  >> it is doing, and if it a programming fault at my end or the correct
  >> "behaviour"
  >>
 >
 > No, closing the browser does not destroy it, only if you pass it on as
 > links (url .SID.).

Hum. I have used in the past

$_SESSION['my_session_variable'] = "blah";

But I thought that once I closed the browser window it was getting wiped.
S'pose it makes sense as the server is storing the data not the client.

Will look at this tomorrow morning. Ta.

 > Sure you can achieve the same thing. how about setting the cookie for
 > every form field on the page that the form posts to... and then reading
 > the same cookies in the page that holds the forim and displaying the
 > data as values in the html part: (value:<? echo $_COOKIE['field_one'];
 > ?>) Now THAT's a pain

That was was what I was I was going to do. Seemed pretty quick to me. Just
made the setcookie() function go recursively through the $_POST array.

Bang, data stored and then echoed out as suggested into the form fields.

I'm obviously missing something here. How will using sessions make this any
faster or less painful?

I get the feeling I'm missing something wonderful due to ignorance, but I
can't see what....
 >> Stay informed about: Stupid setcookie() question... 

I noticed that Message-ID: from
Bonge Boo! contained the following:

 >
 >If I choose to use sessions to store this data, will I encounter the same
 >problem with be "one step behind"?

No. You can save stuff into a session variable and use it straight
away. e.g.
<?php
session_start();
if(isset($_POST['variable'])){
$_SESSION['variable']=$_POST['variable'];
echo "Session variable set: ".$_SESSION['variable'];
}
?>

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs <a rel="nofollow" style='text-decoration: none;' href="http://www.ckdog.co.uk/rfdmaker/" target="_blank">http://www.ckdog.co.uk/rfdmaker/</a>
 >> Stay informed about: Stupid setcookie() question... 

On 21/2/05 11:05 pm, in article etok11h2t39qnmegndffnjg4clf9b4ule8.TakeThisOut@4ax.com,
"Geoff Berrow" wrote:

 > What you can do is this: The first time the page is served it should
 > attempt to initialise a cookie. When the form is posted, the script
 > should check that cookie is set. If it's not give a warning that the
 > session will not be saved. If it is, everything is fine.

The other option is that my form submits back to itself, does the checking
for required fields, and if it passes the verification then creates the
cookies, and then forwards to the next page in the sequence.

That way the "receiving" page will always be receiving the correct cookie
header from the client as they were set on the previous page.

Ok. At least I understand why it was doing what it was doing. Many thanks to
both of you.

Now the crunch question.

If I choose to use sessions to store this data, will I encounter the same
problem with be "one step behind"?

I assume note as the server itself is generating that header info, or do I
need to use some sort of

Ob_start() type stuff to buffer the data until I'm ready to send it to the
browser?
 >> Stay informed about: Stupid setcookie() question... 

Bonge Boo! wrote:
  >> Sure you can achieve the same thing. how about setting the cookie for
  >> every form field on the page that the form posts to... and then
  >> reading the same cookies in the page that holds the forim and
  >> displaying the data as values in the html part: (value:<? echo
  >> $_COOKIE['field_one'];
   >>> ) Now THAT's a pain
 >
 > That was was what I was I was going to do. Seemed pretty quick to
 > me. Just made the setcookie() function go recursively through the
 > $_POST array.

You can imitate a session with less cookie traffic:
- Make unique id and store this in cookie
- Make DB table or file where you store the POSTed values along with the
unique id
- Whenever a form is submitted, compare the stored data and the postdata. If
a new value is posted, update the stored data.

Like that you are free to set the cookie lifetime according to your needs.
Of course you will need to add some kind of cleanup function that deletes
the DB or file entries after the data is finally processed or after a
defined amount of time, if the form filling was not completed.

--
Markus
 >> Stay informed about: Stupid setcookie() question... 

On 22/2/05 12:01 am, in article 2atk111uoro256vu79qa7qju9qfqecccv4.TakeThisOut@4ax.com,
"Geoff Berrow" wrote:

  >> If I choose to use sessions to store this data, will I encounter the same
  >> problem with be "one step behind"?
 >
 > No. You can save stuff into a session variable and use it straight
 > away. e.g.
 > <?php
 > session_start();
 > if(isset($_POST['variable'])){
 > $_SESSION['variable']=$_POST['variable'];
 > echo "Session variable set: ".$_SESSION['variable'];
 > }
 > ?>

Lovely. And many thanks to you both.

Off to get frustrated with my complete inability to program.

Cheers.
 >> Stay informed about: Stupid setcookie() question... 

Markus Ernst wrote:
 > Bonge Boo! wrote:
 >
   >>>Sure you can achieve the same thing. how about setting the cookie for
   >>>every form field on the page that the form posts to... and then
   >>>reading the same cookies in the page that holds the forim and
   >>>displaying the data as values in the html part: (value:<? echo
   >>>$_COOKIE['field_one'];
   >>>
   >>>>) Now THAT's a pain
  >>
  >>That was was what I was I was going to do. Seemed pretty quick to
  >>me. Just made the setcookie() function go recursively through the
  >>$_POST array.
 >
 >
 > You can imitate a session with less cookie traffic:
 > - Make unique id and store this in cookie
 > - Make DB table or file where you store the POSTed values along with the
 > unique id
 > - Whenever a form is submitted, compare the stored data and the postdata. If
 > a new value is posted, update the stored data.
 >

Yes, this is basically what PHP session functions do for you automatically.


--
Oli
 >> Stay informed about: Stupid setcookie() question...