Re: PHP as an ActiveScript Engine

the more code i see the more ideas i have ;) harald. "Wez Furlong" <wez@thebrainroom.com> schrieb im Newsbeitrag news:emaildo3ce66ae59e919.20020518155325.83906@thebrainroom.com... > Hey, > > I've been doing some tinkering over the last 24 hours and I've implemented > IActiveScript (and friends) as a SAPI for win32/IE. > > What does that mean?? Well, it means that you can do things like this: > (in IE) > > <html> > ... > <script language="ActivePHP"> > function clickit() { > > $GLOBALS["window"]->open("http://www.php.net"); > } > </script> > > <img onclick="clickit();"> > </html> > > Yes, that's PHP on the client side! > > You can also invoke the engine for Windows Script Hosts (or any other > IActiveScriptSite implementation), and in theory you can even run scripts > with a mixture of JScript, VBScript, Perl, Ruby and PHP in them, with > methods calling in between the engines :-) > > Oh yeah - you can probably use it for ASP and ASP.NET too (haven't tried > that yet!). > > What I have at the moment is still very experimental; the features that > are missing are: > - no event sinking (apart from declaring handlers in attributes) > - error handler is not yet tied into the script host error/exception > mechanism. > - other engines cannot call into PHP yet. That's because we don't have > a standard method of exporting PHP objects as IDispatch-able COM objects. > > Unfortunately, because PHP is so powerful, it's really not a good idea > to author web pages for public consumption using client-side PHP. > IE will warn you that viewing such a page is unsafe. > I'm not bothered by that: my intention is to use it embedded in a win32 > host application. > > The IActiveScript architecture is not too bad, so implementing this wasn't > such a hardship. However, since the host may have multiple engines on > the same thread, the php4activescript implementation creates a thread for > each instance of a scripting engine. That lead to some "interesting" code > to ensure that the right things were called in the right threads... > > Performance-wise, there are two things that would be really beneficial > for php4activescript - although I dont expect to have these any time > soon, I'm highlighting them in case someone has alternative solutions: > > - Delayed bindings for globals. The scripting hosts register a good dozen > or so COM objects in the global namespace. PHP has to activate and make > a couple of calls for each object imported in that way so that it can > create a COM wrapper object (from the COM extension) for each object, > even if it is not used. It would be nice to activate the object the first > time the global symbol is used. > > - Scripting engine persistance mechanism. Being able to make a persistent > (as in pmalloc) copy of zend_op_array's would do just fine. > I know this is not easy because of all the emalloc'd data in there. > Alternatively, it would be nice to be able to convert a zend_op_array > back into a string representation of the code. The reason for this is > that script hosts will create an instance of the engine, parse the script, > clone the engine and then run the cloned instance. Because of the PHP > architecture, we need to re-compile the code on the newly cloned thread :-/ > > Right, I'm going to delve back into it - I just wanted to sound things out, > and see if anyone has any ideas about these things. > > --Wez. > > > -- > Wez Furlong > The Brain Room Ltd. >