|  | Posted by Jerry Stuckle on 09/08/06 01:37 
CptDondo wrote:> Jerry Stuckle wrote:
 >
 >> CptDondo wrote:
 >>
 >>> Let me explain my situation:
 >>>
 >>> I have a PHP app that generates web pages on the fly based on some
 >>> data it reads from XML files.  The pages are served up via a http
 >>> server and displayed with a browser.
 >>>
 >>> I've been asked to port this to an ANSI terminal-type display,
 >>> eliminating the web server and browser.
 >>>
 >>> Initially I thought about using C to write the app, but XML handling
 >>> in C is a real PITA, plus I don't get to reuse my PHP code.
 >>>
 >>> So, now I want to use PHP to generate those same pages except that I
 >>> don't want to send headers ever, and I need to loop waiting for
 >>> characters to arrive from the keypad and display pages based on those
 >>> chars...
 >>>
 >>> This is on an embedded platform, and I really need to be able to use
 >>> a single PHP binary for both purposes (the displays are
 >>> interchangeable at the hardware level; it all depends on what the
 >>> customer pays for.)
 >>>
 >>> How do I get php to act as just another scripting language?
 >>>
 >>> Thanks,
 >>>
 >>> --Yan
 >>
 >>
 >> Yan,
 >>
 >> If you're running on a web server, the headers will always be sent.
 >> PHP doesn't send the headers, the web server does.
 >
 >
 > OK, I'll play with it a bit...  I've never quite figured the difference
 > between php-cgi and php-cli.  They both seem to do the same thing.  As
 > my embedded system is tipping the scales at 32 MB, I am doing what I can
 > to eliminate unnecessary bloat....
 >
 
 It's pretty simple.  The CGI or web server integrated interface uses the
 web server for I/O operations - you don't have to open a socket to the
 client, for instance.  It also gets additional value from the web server.
 
 The cli version is just that - a command line version.  It doesn't run
 under the web server; rather it interfaces to the command line directly.
 But if you want to talk to a remote system, either that system has to
 telnet/ssh into a command line prompt or you have to do your own socket
 work.
 
 >>
 >> You can run it as a batch job, in which case the headers won't be
 >> sent.  But while you'll probably be able to use some of the code, you
 >> won't be able to easily make the same program work both ways.  At
 >> least not without a lot of if($onwebserver){...} else {...} constructs.
 >>
 >> Probably better to create two files and one or more include files for
 >> the code you can use in both.
 >
 >
 > Well, the idea was to split the existing code into a front end and a
 > back end, where the back end does the XML parsing and manipulation, and
 > the front end handles the display end of things.
 >
 > That way I can reuse the back end code for both display modes without a
 > snakes' nest of if ... else...  :-)
 >
 
 No problem with that.
 
 > --Yan
 
 
 
 --
 ==================
 Remove the "x" from my email address
 Jerry Stuckle
 JDS Computer Training Corp.
 jstucklex@attglobal.net
 ==================
 [Back to original message] |