Re: [PHP] Re: How to run one php app from another? RECAP
On 6/16/06, tedd [EMAIL PROTECTED] 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. Any links (direct or via a form) are objects that the browser can act upon per the user through html or js, but not php. Interesting. Perfectly doable in PHP. Just have the form action go to a new php script and do your logic, then use header(location:...) to redirect. Gerry -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Slow loading (was Re: [PHP] Re: How to run one php app from another? RECAP)
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 scriptlocation.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
[PHP] Re: Slow loading (was Re: [PHP] Re: How to run one php app from another? RECAP)
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 scriptlocation.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
[PHP] Re: How to run one php app from another? RECAP
tedd schrieb: 1. There was the suggestion to use includes(). However, includes simply adds code into the current application. It does not terminate the parent nor start another application. It simply bloats the parent. Well it would if the webpage showed would also be included. You have one main code header which chooses what action to do and which code to load. So every app would have that code header. Applications run normally like that. You could even have tha analyzing done with include. But once output is made. You can't remove it. That isn't possible with PHP. Anything before that would not be seen by the user so you can do a lots of things before you output actually something. Barry -- Smileys rule (cX.x)C --o(^_^o) Dance for me! ^(^_^)o (o^_^)o o(^_^)^ o(^_^o) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: How to run one php app from another? RECAP
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. Any links (direct or via a form) are objects that the browser can act upon per the user through html or js, but not php. Interesting. Thanks. 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
Re: [PHP] Re: How to run one php app from another? RECAP
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. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: How to run one php app from another? RECAP
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
Re: [PHP] Re: How to run one php app from another? RECAP
On Fri, June 16, 2006 4:04 pm, tedd wrote: 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? Yes -- Though your concept of PHP being finished with and the Reality *might* not match up. They probably will, but, for example, if you had all of War and Peace in $foo and did: echo $foo; I am not going to guarantee that PHP won't send it out chapter by chapter and PHP won't be finished with the echo before the browser gets and renders Chapter 1. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
