Javascript was originally developed by Netscape, and was built right into the Netscape browser engine. Javascipt has no relation to Sun Java what-so-ever. I think Netscape named its code "Javascript" to play on the popularity and buzz of SUN java language. Anyway, javascript became so popular that other browsers incorporated javascipt, and javascript is now a standard language for coding against the client's browser of choice on the workstation.

It might be difficult to build a scripting language in VFP that a browser would be able to recognize. I suppose it would require accessing the browsers API, so it would recognize the VFP .dll scripting engine. Perhaps the VFP .dll could be put into the browser's Plugin directory, much like flash, or SUN Java, so the browser could pass the VFP scripting code to the VFP .dll for execution.

If the VFP .dll could access the VFP database engine through ODBC or OLE DB, I suppose it would be possible to connect to a VFP database to insert,delete, update, and select records. In this scenario each workstation would require at least a couple of downloads, including the VFP scripting .dll, to be placed in the browsers Plugin directory, and VFP itself. This might mean the web site could only be access by users running the window OS, so it wouldn't be very cross platform friendly. It could also create some stability problems running a browser that passed code embedded in the html to a scripting VFP .dll, instead of having code running in the browser engine itself, and the VFP .dll in turn passing code via ODBC, or OLE DB to the VFP engine. Another serious challenge would be locking everything down, so there could be no security breaches regarding viruses or spyware, etc. Of course javascript suffers many of the these same challenges.

Given that the browser engine would require a separate download of a VFP scripting .dll, would require VFP itself, would limit the client browser to the windows OS, and would create possible security concerns, I don't see how this would be any kind of advantage over have a VFP fat client that accessed VFP, MSQL, PostgreSQL, MySQL databases and tables via their respective drivers over TCP/IP.

Regards,

LelandJ


>The xharbor solution involves changing the script language tag in the web page from Javascript to xbscript. Then as long as the xbscript.dll is on the workstation the browser runs the xbscript just as easily as Javascript. So the technical part is building the vfpscript.dll.
>
>Simon
>
>>>Hi
>>>
>>>I was viewing some information at www.xharbor.com about their xbscript.dll which allows you to write script code in web pages using the xharbor language. So if people dislike using Javascript why not build a VFP scripting dll that would allow VFP code to be used in web pages and processed on the client using a VFPScript DLL?
>>>
>>>What are the advantages/disadvantages of such an idea? Any thoughts on the value of such a tool?
>>>
>>>Simon
>>
>>Most of the browsers have built in support for html and javascript, so it would not be a trivial task to get all the browsers to support VFP.
>>
>>Regards,
>>
>>LelandJ