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.
> >
> > --Wez.
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
