It might be of help when migrating from ASP to PHP. If you can pass values(?) between ASP and PHP then you might be able to convert incrementally from ASP to PHP.
For applications that have too much code to convert (and test!) in one release cycle, this could be a significant advantage. You *do* expect folks to convert from ASP to PHP someday? :) From: Michael Dransfield [mailto:[EMAIL PROTECTED]] > it would make migration from asp to php easier... sell it to your clients > as enhanced asp, then show then the benefits of the php additions > > thats all i can think of ;) > > Mike > > At 20:59 19/05/2002 -0700, Rasmus Lerdorf wrote: > >Ok, so that is how it works. Could you talk a little bit about why > >anybody would want to do this? > > > >On Mon, 20 May 2002, Wez Furlong wrote: > > > > > Well, I've added the new activescript sapi to CVS; it's still experimental, > > > but it should work for quite a few uses. > > > > > > I've tested it with IE using syntax like this: > > > > > > <script language="ActivePHP"> > > > $window->alert("hello"); > > > </script> > > > > > > <input type="submit" value="clickme" onclick="$window->alert("hello");"> > > > > > > It also works with the Windows Scripting Host; you can either explicitly > > > set the engine on the command line like this: > > > > > > cscript //e:ActivePHP myscript.php > > > > > > or you can use a .wsf file like this: > > > > > > <job id="test"> > > > <script language="ActivePHP"> > > > $WScript->Echo("hello"); > > > </script> > > > </job> > > > > > > ASP should also work; something like this should do the trick (untested!) > > > <%@lanugage=ActivePHP%> > > > <% > > > $Response->Write("hello"); > > > %> > > > > > > It should also be possible to write a windows script component as well. > > > > > > Caveats/Notes: > > > There may be some threading issues, particularly with multi-threaded > > > scripting hosts (WSH and ASP). The scripting host architecture says > > > that the engine should be free threaded, but then forces callbacks > > > to occur on a particular thread. On top of that, we need to contain > > > all PHP state in a thread of it's own. There's some interesting code > > > in there... > > > > > > If you use multiple scripting languages in a script/job, the other > > > languages will most probably be able to access PHP globals, but PHP > > > will not be able to access their globals unless the scripting host > > > explicitely registers them in the PHP global namespace. > > > However, you can use expandos on an existing global object to share > > > data between engines: > > > $window->foo = new foo(); > > > will add the object foo as a property of the window object in IE. > > > JavaScript should then be able to access it: property access and > > > method calls are implemented (only for non-overloaded objects!). > > > > > > echo and print will send output to the debugger, not to the browser, > > > console or a message box. It might be possible to tie it into IE, > > > but that will require some investigation (query the script site for > > > one of the well-known IE interfaces?). > > > > > > Currently, the main engine object is implemented in C++, which has > > > a few annoying compilation quirks when mixed with C. I plan to > > > rewrite it in plain old C, so don't panic. > > > > > > I'm using a recent platform SDK, so if you get warnings/errors > > > concerning IActiveScriptParseProcedure, you need a newer set of headers. > > > > > > I've added a generic COM wrapper for PHP objects to the COM extension: > > > you will be able to use it with other win32 sapis to pass PHP objects > > > to COM servers that expect an IDispatch-able object. The same mechanism > > > could be extended to have the COM wrapper act as an event sink. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
