PHP tends to send output in content transfer encoding "chunked" (I think
this is true when output buffering is on). <?php ?> blocks usually have
their output sent in one chunk. The browser renders the chunks as they
come, but oftentimes they delay rendering until a sensible number of
HTML closing tags have arrived.
Now, on to the real answer to your question. No, under normal
conditions you can't have your users' browsers interact with a live PHP
script. Web programming is Web REQUEST->PHP RESPONSE, and you must use
support technology (like sessions, cookies or manual carryover of form
data) to make session state persistence possible.
In other words: no, if the user clicks a button, it doesn't "call a
function or branch in an if/then control statement" immediately.
Rather, an entirely new PHP process, totally unaware of the former one,
is called upon to service that request.
Now, while in the PHP realm, there *is* one way to have your web client
follow the pattern "REQUEST->RESPONSE,RESPONSE,RESPONSE" ad infinitum.
This is called slow loading (or Comet), and basically involves:
- having the web client load a PHP script through a hidden IFRAME
- having the PHP script *never* finish execution (unless, of course, the
user hits Stop in his browser window), and continually send data through
the connection (plus one ob_flush() after each chunk just to be
politically correct). Usually, data payloads ("page updates") are to be
carried on via JavaScript snippets, because that's about the only
technology that allows for browser state manipulation "in vivo", I mean,
live as the connection goes and never finishes.
Given a properly architected solution, this kind of technology can
outperform the famous AJAX, both in response times and in server load.
Given a poorly done solution, this kind of technology can be as bad or
dramatically worse than AJAX.
Plus, you gotta remember that PHP usually has a maximum duration on
scripts, so you need to architect around that (which isn't hard to do,
namely you have a counter and as the counter approaches the maximum load
time, just a few seconds earlier you send a <script>location.href
= ...</script> to have the browser reload the IFRAME, and exit() your
PHP script.
El vie, 16-06-2006 a las 17:04 -0400, tedd escribió:
> At 3:52 PM -0500 6/16/06, Richard Lynch wrote:
> >On Fri, June 16, 2006 8:26 am, tedd wrote:
> >> At 2:35 PM +0200 6/16/06, Barry wrote:
> >>>But once output is made. You can't remove it.
> >>>
> >>>That isn't possible with PHP.
> >>
> >> I think I get it now.
> >>
> >> PHP does everything before the user see's anything.
> >
> >This is not quite 100% correct...
> >
> >PHP output is buffered, possibly by PHP with ob_start and friends, and
> >then possibly by Apache, and then possibly by TCP packets and their
> >ordered arrival (or not) and then by the browser, but...
> >
> >It is entirely possible to construct a trivial example proving that
> >PHP can still be runing and finishing output while the browser has
> >rendered the beginning of the page.
> >
> >You can mostly THINK of it as PHP finishing before user sees anything,
> >as that will get you in a lot less trouble than thinking the other way
> >around, but to be pedantic, you should be aware it's not quite that
> >simple.
>
> Good explanation and point.
>
> How's this for the obvious -- the user doesn't see anything until php is done
> with it. That doesn't mean that the entire operation must be finished, but
> rather anything that the user see's (while and after loading) php has already
> finished with.
>
> That about right?
>
> tedd
> --
> ------------------------------------------------------------------------------------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
