Manuel:
Thank you for your most detailed explanation -- I must admit most of it is over
my head. However, I shall study the concept further and place your email in my
"to learn" collection (I have one and it's growing faster than I can keep up).
But as of now, I can now run one php application from another, which was the
request that started this thread.
tedd
----
At 3:48 AM -0500 6/19/06, Manuel Amador (Rudd-O) wrote:
>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
>>
--
------------------------------------------------------------------------------------
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
