Variable Scope

[doubledee]

I have an HTML form with a Dropdown list off dates.

 

The Dropdown is populated using PHP and an array...

<?php
$concertDates = array('201105071'=>'May 7, 2011 (9:00am - 12:00pm)',
				'201105072'=>'May 7, 2011 (1:00pm - 4:00pm)',
				'201105141'=>'May 14, 2011 (9:00am - 12:00pm)');
?>

 

When my HTML form is re-submitted to itself, what happens to $concertDates??

 

I was under the impression that it remains alive as long as my script is running...

 

 

 

Debbie

 

 

[PFMaBiSmAd]

Yes, but your script is NOT still running at the time your form gets submitted.

 

Web servers are stateless. They don't know or care what happened before the current http request or what will happen after the current http request. They blindly service each http request they receive. When they finish servicing one http request, all the resources used on the page that was requested are destroyed. They are not sitting there waiting for a form to be submitted because they don't know or care what is on a web page, they just output the web documents that get requested.

 

Here is what happens when a form is requested and that form is submitted -

 

1) A http request is made for a page that happens to output the html that makes up a form. The web server reads the file that corresponds to the page that was requested and outputs it to the browser. If that page happens to contain any php code, that php code is parsed, tokenized, and interpreted. Any output that the php code produces is sent to the browser.

 

2) The browser receives the html that was output by the server and renders it. If that html produces a form, you now have a form sitting in front of the visitor.

 

3) When or even if that form is finally submitted, it is submitted to the URL that is in the action="" attribute in the <form> tag. This results in a http request to that URL and hopefully there is some php code on the page that gets requested that will detect and process the submitted form data. This http request is completely separate from the http request that caused the form to be output to the browser.

 

The only thing that ties the two http requests (form and form processing) together is the information that comes as part of the http request. This includes the IP address that the request came from, any cookies (including a session id cookie), information that is part of the URL, and any information that is submitted as form data.

 

Edit: Short-answer: Even if your form and your form processing code are on the same page, each request for that page is completely separate. It is up to the logic you put onto that page to decide what to do for any particular request - output the form or detect and process the form submission.

[doubledee]

After wasting the last 8 hours of my life, I just discovered this as you typed.

 

So....

 

If I build my array on page 1 (i.e. displayed form) and then I need to access that same array on page 2 (i.e. processed form), then I would need to use a Cookie, Session, or Database to maintain the "state" of said data/array, right??

 

 

Debbie

 

 

[PFMaBiSmAd]

If you are dynamically building up some data on one page, you would generally use a session to pass that information, for the duration of a browser session for one visitor, between different pages or requests for the same page. If you need that information to persist longer than one browser session or for it to be available to different visitors, you would generally store it in a database table.

[doubledee]

How do I use Cookie-less Sessions?

 

 

Debbie

 

 

[doubledee]

Also, if I have a form field, "firstName" then that get sent in $_POST which does maintain state from submitted form to processed form, right?

 

But what get put into $_POST on drop-down lists?

 

Just the selected value?

 

Or the entire drop-down list?

 

 

 

Debbie

 

[trq]

Generally speaking sessions require cookies. You can configure PHP to pass your session data through the url but it is generally avoided these days and is switched off by default.

[PFMaBiSmAd]

By default, the session id is passed using a cookie. It is best to use it this way.

 

The only other choices are to pass that session id on the end of the URL or to pass it as hidden form data (assuming there is a form.) Since php will only automatically pass the session id on the end of relative URLs on your site, you end up writing code yourself to insure that the session id gets passed as part of the URL in all cases and if someone leaves your site, the session will be lost if the URL looses the session id on it.

[doubledee]

Let me stress I'm on time-constraints here...

 

So this mini-project is to get a description of the Concert Date someone selected for their receipt.  (i.e. critical)

 

If they have "cookies off" then I guess I'm screwed?!

 

 

 

Debbie

 

[PFMaBiSmAd]

If they have "cookies off" then I guess I'm screwed?!

 

I don't recall anyone stating that you cannot get sessions to work when cookies are turned off.

[doubledee]

If they have "cookies off" then I guess I'm screwed?!

 

I don't recall anyone stating that you cannot get sessions to work when cookies are turned off.

 

I thought you and Thorpe recommended I use Sessions that require Cookies, right?

 

Well, if Joe User has "Cookies Off/Blocked", then the Session won't work, right?

 

 

Debbie

 

 

[KevinM1]

If they have "cookies off" then I guess I'm screwed?!

 

I don't recall anyone stating that you cannot get sessions to work when cookies are turned off.

 

I thought you and Thorpe recommended I use Sessions that require Cookies, right?

 

Well, if Joe User has "Cookies Off/Blocked", then the Session won't work, right?

 

Debbie

 

Easier to link to some answers than rehash them:

 

http://stackoverflow.com/questions/3740845/php-session-without-cookies

 

But, really, this is 2011.  If someone has cookies turned off, they're doing it wrong.

[doubledee]

Easier to link to some answers than rehash them:

 

http://stackoverflow.com/questions/3740845/php-session-without-cookies

 

But, really, this is 2011.  If someone has cookies turned off, they're doing it wrong.

 

Maybe, I'd just hate to have my Concert Ticket/Receipt screwed up because they have Cookies Disabled and so I can't print what I need to from my Session.

 

Until I have time for a more robust solution, I guess I'll just have to add a warning in red to accept cookies?!

 

 

 

Debbie

 

 

[ManiacDan]

You can avoid this entire problem by thinking about your architecture:

When my HTML form is re-submitted to itself, what happens to $concertDates??

If your form re-submits to itself, then the same code will be running.  Put this code that generates $concertDates at the top of the script, before any if/else check to see if the form has been submitted.  That way, $concertDates will be available no matter what path this form takes. 

 

As for sessions and cookies:  The web is stateless.  Once you get a page, the script that made that page is dead and the web application will never know who you are when you submit the form.  We solve this problem by keeping a unique identifier in the cookies so we can track a user's progress through the site.  This, when combined with a set of data that's necessary to maintain a user's state, is called the session.  Generally it's done using cookies.  Rarely, it's done with the session ID in the URL.  This is generally considered a terrible, terrible idea, and is turned off by default in PHP.  It breaks bookmarking, and if a user emails the URL of your site to someone else, the recipient will automatically hijack the first user's session (since it's part of the URL).  If your users have cookies off, they're not browsing the web properly anyway.  They wouldn't be able to use phpfreaks, facebook, or even gmail.  Without cookies, the web is static and impersonal.  If they want to use the web, they'll turn cookies on.  Don't even bother writing for cookie-less users unless you discover it's a major portion of your userbase.

 

-Dan

 

P.S. Yes, the same ManiacDan from DevShed, I'm a mod over here as well.  We do want to help.

[doubledee]

You can avoid this entire problem by thinking about your architecture:

 

I got it fixed using a session for now.

 

Once the site is up, then I'll go back and start using things like a database which will solve lots of these issues.

 

 

As for sessions and cookies:  The web is stateless.  Once you get a page, the script that made that page is dead and the web application will never know who you are when you submit the form.

 

I figured that after 8 hours yesterday!

 

 

Rarely, it's done with the session ID in the URL.  This is generally considered a terrible, terrible idea, and is turned off by default in PHP.

 

Yep, got that.

 

 

If your users have cookies off, they're not browsing the web properly anyway.  They wouldn't be able to use phpfreaks, facebook, or even gmail.  Without cookies, the web is static and impersonal.  If they want to use the web, they'll turn cookies on.  Don't even bother writing for cookie-less users unless you discover it's a major portion of your userbase.

 

I require manual approval on my laptop.

 

And I often lock myself out - temporarily - from a site's features...

 

My fear was that most users aren't smart enough to fix a blocked cookie?!

 

Guess I'll hope they accept them so it doesn't mess up my session?!

 

 

-Dan

 

P.S. Yes, the same ManiacDan from DevShed, I'm a mod over here as well.  We do want to help.

 

Good, because when people talk to me (versus down to me), I'm the best pupil on the Internet.

 

Thanks,

 

 

Debbie