Latent PHP Code

[iwato]

QUESTION: Is it possible to write PHP code into a file that is not processed the first time it is passed to the webserver?OBJECTIVE: I want to create a PHP file that contains two sets of PHP code: one set that is processed when the file is first sent to the interpreter, and another set that is triggered by the user only after the page has been displayed in his browser window.If this is possible, what is it called and how is it done, short of using the include() or require() function.Roddy

[Synook]

Perhaps you want to use AJAX?

[jeffman]

Use a session or some other cookie?

[iwato]

Perhaps you want to use AJAX?

I will check it out. Can you give any further clues?Roddy

[iwato]

Use a session or some other cookie?

Yeah, I have seen the topic title "session" on more than one occasion and wondered what it was. Now I have a good reason to dig more deeply. Thank you.Roddy

[boen_robot]

Depending on what exactly you want to run after the first page has loaded, using any of the described approaches is the way to do it. Which one exactly is appropriate depends on the scenario.Using a session is appropriate if you want to execute certain things per user (by default, regardless of computer). The procedure is this: When the HTTP request starts, it may or may not include a special value (a cookie) that should uniquely identify the user. If there's no such value, a cookie having an appropriate (unique) value MAY be given to the client (in most cases, only on certain conditions - having appropriate username and password) to supply with their next requests. If there is such a value (i.e. if an appropriate cookie was given; the username and password were entered successfuly at some point in the past), you get a superglobal variable named $_SESSION that contains data associated with this value. The things in $_SESSION get filled up on every request that contains an appropriate cookie, and keep being filled there until the session expires (typically, that's somewhere around a few minutes without PHP receiving a request with an appropriate cookie).Using a cookie is appropriate if you want to execute certain things per computer (regardless of user). The procedure is similar to the session, minus the $_SESSION superglobal and the "unique" value. The value is instead not unique, and just defines something that was given previously to the HTTP client. Your script could assume that if the client has such a value, it should do a certain thing, and it should do it every time a request has that cookie.Using AJAX is appropriate if you want to make a separate HTTP request that doesn't result with the user seeing something. Instead, your JavaScript code will store the result (which may be generated after PHP does something on that new HTTP request), and from that point on, it can do whatever you tell it to do. For example, you may inspect what the response says, and make JavaScript do different things based on it.

[iwato]

Your description of both sessions and cookies was quite understandable. I was less able to follow your explanation of AJAX, but probably have understood enough to know which way to go -- at least for the moment. So, many thanks.This entry will be bookmarked.Roddy

[boen_robot]

It's kind of odd that AJAX was the one you were less able to follow... it's the very thing you described in your first post, only separated into two PHP invokations (two HTTP requests) as opposed to one PHP invokation (one HTTP request), which is what you were describing.The first time (the first HTTP request), when you type an address in the browser or click a link, PHP loads the HTML page, that may contain some JavaScript. The JavaScript code itself is attached to events that occur on the page (the user clicking on a button, the page being finished with loading of any images, etc.). Part of the code for an event may contain JavaScript code that makes a new HTTP request. This separate HTTP request may be a request to a PHP file that happens to dynamically generate something. Instead of having the content from that request appearing on screen, as it happens when you type an address or click a link, the content is instead available from JavaScript itself. After you've made the request with JavaScript, you can make JavaScript do anything with the response, including displaying it on screen.The technique of using JavaScript to send HTTP requests is nowadays reffered to as AJAX.

[iwato]

It's kind of odd that AJAX was the one you were less able to follow... it's the very thing you described in your first post, only separated into two PHP invokations (two HTTP requests) as opposed to one PHP invokation (one HTTP request), which is what you were describing.

What one wants is not always what one gets.Also, someone who takes a general interest in something is receptive to a large number of inroads that are not necessarily related to his immediate goal.In any case, I think I have got it now. Let's see.

This separate HTTP request may be a request to a PHP file . . . Instead of having the content from that request appearing on screen, as it happens when you type an address or click a link, the content is instead available from JavaScript itself.

Are you saying that the PHP code written in the second PHP file called by the second HTTP-request can send information to Javascript code contained in the already displayed page, and that this Javascript code can then be further acted on by the user without reloading the displayed page? Have I understood correctly?

The technique of using JavaScript to send HTTP requests is nowadays reffered to as AJAX.

Based on everything you have already said, would it be any more correct to write "send and receive HTTP-requests" instead of only "send HTTP-requests"?It looks I have opened still another area of exploration that I have shunned thus far -- HTTP Authentication and HTTP. Any other suggestions in prepartion for AJAX?Roddy

[boen_robot]

Are you saying that the PHP code written in the second PHP file called by the second HTTP-request can send information to Javascript code contained in the already displayed page, and that this Javascript code can then be further acted on by the user without reloading the displayed page? Have I understood correctly?

Basically, yes.

Based on everything you have already said, would it be any more correct to write "send and receive HTTP-requests" instead of only "send HTTP-requests"?

Well... yes. However, you are not required to do anything with the response, so from your perspective, the fact that you've sent a request is still AJAX... you are indeed receiving data every time as well, but if you aren't doing anything with it, adding "receive" to the definition is somewhat redunant.

It looks I have opened still another area of exploration that I have shunned thus far -- HTTP Authentication and HTTP. Any other suggestions in prepartion for AJAX?

Study those things separately before you try to combine them with AJAX. That's all I can say for now as a tip.The HTTP extension is to PHP like what AJAX is to JavaScript - a way to get the language to send HTTP requests and receive HTTP responses, which are stored in it. Fo some reason, the HTTP extension has far more extras than the XMLHttpRequest object in JavaScript.

[justsomeguy]

Based on everything you have already said, would it be any more correct to write "send and receive HTTP-requests" instead of only "send HTTP-requests"?

Technically it's correct to say that the browser (Javascript) sends requests and receives responses, and the server receives requests and sends responses.

[iwato]

Study those things separately before you try to combine them with AJAX. That's all I can say for now as a tip.The HTTP extension is to PHP like what AJAX is to JavaScript - a way to get the language to send HTTP requests and receive HTTP responses, which are stored in it. Fo some reason, the HTTP extension has far more extras than the XMLHttpRequest object in JavaScript.

OK. HTTP and HTTP Authentication ahoy!Roddy

[iwato]

Technically it's correct to say that the browser (Javascript) sends requests and receives responses, and the server receives requests and sends responses.

It's the simple things in life that count.. . . And, getting the server and client relationship right is essential!Thanks!Roddy