On Wed, 20 Jan 2010 20:05:42 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote:
>2010/1/20 <clanc...@cybec.com.au>: >> When you are working with sessions, provided you start your program with >> session_id(), you >> can then do anything you like with session variables at any point in your >> program. > >Hi, > >You meant session_start() instead of session_id(), right? Yes; Oops! > But yes, >once you started a session (before any output is sent to the browser, >that includes echo and print statements, empty space chars, etc) you >can do anything you like with the $_SESSION array, being able to read >the stored values in other requests / scripts of your app, as long as >the session is started. > >> In my >> original question I asked if there was a cookie equivalent. > >As far as I know, yes, there is. You set a cookie using the >setcookie() function. This function, in the same way as >session_start(), must be called before any output is sent to the >browser. Once a cookie is set in the client, you can read the $_COOKIE >array in any subsequent request of your client, in any point of your >app, just like session. It is not equivalent if you can't set a cookie after you have generated any output. > >> >> Someone said there was, but the above is simply demonstrating that their >> suggested >> solution doesn't work. It appears there is no solution, but that the >> workaround is to turn >> on output buffering, at least until you finish setting cookies, so that you >> can be certain >> that no output is generated before this point. > >You don't need to use output buffering at all. You only need this >mechanism if your script needs to output stuff before the >session_start() or setcookie() functions get executed. I don't NEED output buffering if I put the cookie handling logic right at the start of the program, and don't ever want to put any diagnostics into it. But there is a logical place for it much later in my program, and I often want to put diagnostics into even the simplest bit of code, and life is much easier if this doesn't disable the cookie handler. > >Well, I hope this information is helpful. Yes, thanks to everyone who contributed. I now have a better understanding of what cookies are, and have turned on output buffering, enabling me to put the handler where I want, and still be able to debug it. Clancy >Cheers, >Bruno. > >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
