Using php

[Jan Schenkel]

--- Pierre Sahores <psahores at easynet.fr> wrote:
> Le mer 18/02/2004 à 04:16, Shari a écrit :
> > >Shari,
> > >
> > >If you control the php script, you can always
> return simple HTML 
> > >than will render using a field's htmlText
> property, and display that.
> > >You can also just search for the name in the
> HTML.
> > >
> > >HTH,
> > >Brian
> > >
> > >>The .php script can dynamically insert a
> person's name onto a web 
> > >>page, to personally thank them or whatever.  But
> for my Metacard 
> > >>script to go to that web page and check to make
> sure the name is 
> > >>there, fails.  When you "get" an URL, what you
> are getting is the 
> > >>raw HTML, not the finished page the surfer sees.
> > 
> > Brian,
> > 
> > I tried that last night, using a real web page on
> my site.  The php 
> > script replaces a dummy word with the desired one,
> and the page you 
> > see has the newly inserted word.  When I retrieved
> the page from 
> > Metacard, it retrieved the raw HTML with the dummy
> word, not the web 
> > page it produced with the newly inserted word. 
> Same problem I had 
> > with CGI.
> > 
> > Am I missing something?
> > 
> > I need to be able to "get" what is displayed, not
> the raw HTML behind 
> > it.  Barring that, the only solution would be to
> have a text file or 
> > HTML page that is actually updated, not
> temporarily for one view, but 
> > permanently.
> > 
> > Shari
> 
> Shari,
> 
> It's no way to have the same html page parsed by
> both PHP and a second
> server-sided parser (including MC/Rev CGI) in the
> same time (in a
> cascading parsing way).
> 
> What can be done instead is to use PHP as a sockets
> listener binded, one
> side, to the standard 80 Apache's port and, second
> side, to an root
> protected port (under 1024) or unprotected port
> (over 1024 - not always
> a good practice) binded to an MC/Rev application
> launched in the
> background (console or X11/Quartz modes) and
> including a stack script
> handler set like below :
> 
> [snip]
> 
> In this way, you will be able to build rocking
> MC/Rev applications servers, able to run faster than
> the best J2EE 
> solution available today (JBoss) applications
> servers does, instead of, just, slow and a little
> capricious MC/Rev CGIs.
> 
> Hope this help ;-)
> 
> -- 
> Bien cordialement, Pierre Sahores
> 

Bonjour Pierre,

I would really like to thank you for sharing this
information ; I had been experimenting with the
CGI-engine, as well as an adapted version of the good
old mchttpd.mc stack as webserver.
But in both cases, I was concerned with the speed : if
the cgi has to be loaded completely and connect to a
database etc. every single time that's an enormous
overhead ; and using MC/RR as a webserver without
multithreading sounds like a suicide mission.

The above scenario lets every app do what it does
best, with the least overhead : Apache can serve
files, PHP can do its hypertext processing, and the
MC/RR app can be launched at starup, connect to the
database and react to queries without having to serve
up static content.
And if the speed is as good as you keep telling us,
then that's even more proof of MC/RR as an excellent
platform for developing distributed business
applications.

Best regards,

Jan Schenkel.

PS: the thing I never really got about this setup was
how PHP connected to MC/RR sockets ; with the sample
code you posted, it's all become crystal clear :-)

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools