is it possible to call vbs file with js?

[rgintexas]

i'm trying to get server side vbscript to execute in firefox:

</script>
<script type="text/VBScript" src="VBFile.vbs">
</script>

is there any way i can use javascript to call the vbs file, or is there
any other method for getting server side vbscript to execute within
firefox?

 

[VK]

i'm trying to get server side vbscript to execute in firefox:

</script>
<script type="text/VBScript" src="VBFile.vbs">
</script>

is there any way i can use javascript to call the vbs file, or is there
any other method for getting server side vbscript to execute within
firefox?

Firefox doesn't support VBScript (nor any other browser except IE). You
can use an ajaxoid to address your server side script as a regular URI
and get the execution results in response:
....
xmlhttp.open('GET','myServerSide.asp',true);
....

 

[Randy Webb]

VK said the following on 5/19/2006 2:32 AM:

Firefox doesn't support VBScript (nor any other browser except IE).

You missed the important part of the question though. "getting server
side script to execute in firefox" and the answer is quite simple.
Server side code will *never* execute in the browser. It doesn't matter
what language it is.

If VBFile.vbs generates JS code, you simple change the type attribute to
text/javascript:

You can use an ajaxoid to address your server side script as a regular URI
and get the execution results in response:

I would ask you what you think an "ajaxoid" is but your explanation
might give me a headache.

 

[VK]

I would ask you what you think an "ajaxoid" is but your explanation
might give me a headache.

"ajaxoid" is a lexical compromise between "AJAX" (so be beat down for
using "stupid bizwords") and "IXMLHTTPRequest/XMLHttpRequest solution"
(so loosing skin on my finger tips by typing it).

If you have a better variant, I'm open for proposals.

 

[Randy Webb]

VK said the following on 5/19/2006 3:33 AM:

"ajaxoid" is a lexical compromise between "AJAX" (so be beat down for
using "stupid bizwords") and "IXMLHTTPRequest/XMLHttpRequest solution"
(so loosing skin on my finger tips by typing it).

If you have a better variant, I'm open for proposals.

"Unreliable technology pushed by boardroom pundits"

 

[VK]

VK said the following on 5/19/2006 3:33 AM:

"Unreliable technology pushed by boardroom pundits"

Only as an acronym then: UTPbBU, otherwise no better than
"IXMLHTTPRequest/XMLHttpRequest solution"

 

[Erwin Moller]

VK said the following on 5/19/2006 3:33 AM:

"Unreliable technology pushed by boardroom pundits"

Hi Randy,

You just made me very curious: Why do you call AJAX unreliable?

I've just implemented a few AJAX-based solutions at some customers, which
work 100% so far, so your remark gives me the creeps. :-/

What is wrong with AJAX at the moment?


Regards,
Erwin Moller

 

[Randy Webb]

Erwin Moller said the following on 5/19/2006 8:32 AM:

Hi Randy,

You just made me very curious: Why do you call AJAX unreliable?

Lack of wide spread support. It is gaining support in MAC browsers but
it has a long way to go before I would consider it reliable enough for
an Internet site.

I've just implemented a few AJAX-based solutions at some customers, which
work 100% so far, so your remark gives me the creeps. :-/

What is wrong with AJAX at the moment?

Lack of wide spread support mostly. Especially when a more reliable
approach works.

 

[Roman Ziak]

You missed the important part of the question though. "getting server
side script to execute in firefox" and the answer is quite simple.
Server side code will *never* execute in the browser. It doesn't matter
what language it is.

This is slightly off the original topic: if server-side was running
JavaScript (or other language supported by both sides), scripts could be
shared between server and client (e.g. parsers, validators, HTML forms
generators, etc). Only restriction would be that shared code would not
use environment specific features, e.g. server variables or window
object. Some specific features could be abstracted, e.g. the same script
could make HTTP requests either from server or from client and parsing
responses afterwards.

Roman

 

[Randy Webb]

Roman Ziak said the following on 5/20/2006 7:53 AM:

This is slightly off the original topic: if server-side was running
JavaScript (or other language supported by both sides), scripts could be
shared between server and client (e.g. parsers, validators, HTML forms
generators, etc).

They can share the same code text, yes. But they won't share the same
script block.

Only restriction would be that shared code would not use environment
specific features, e.g. server variables or window object.

I don't see any benefit to that kind of generic code.

Some specific features could be abstracted, e.g. the same script
could make HTTP requests either from server or from client and parsing
responses afterwards.

It wouldn't be the same script block, it may be the same script text but
you can't have a script that executes in either place. If it is marked
to execute on the server, then the client shouldn't ever see it. If it
is marked for the client, then the server won't execute it.

 

[Thomas 'PointedEars' Lahn]

What is wrong with AJAX at the moment?

Besides of being used a (commercial) buzzword, often without regard to its
actual meaning and history: ActiveX support is required for "AJAX" to work
in IE. Furthermore, many (incompetent) people implement "AJAX" and do not
think about clean degradation, for cases where "AJAX" support is not
available, anymore, because it "works" (for them). See also Prototype,
which is really the last piece of code junk but widely implemented anyway
for "AJAX" functionality. Then those people start wondering why their
stuff does not work in IE below version 6 or without ActiveX support or
in $notThatWidelyDistributedUserAgent.


PointedEars

 

[Roman Ziak]

Roman Ziak said the following on 5/20/2006 7:53 AM:

They can share the same code text, yes. But they won't share the same
script block.


I don't see any benefit to that kind of generic code.

Example: server side script "prints" HTML into the network stream,
client side script "prints" the HTML into the document object. One could
abstract the "print()" function and use the same script to render
widgets in browser *or* on the server if browser does not run JS.

It wouldn't be the same script block, it may be the same script text but
you can't have a script that executes in either place. If it is marked
to execute on the server, then the client shouldn't ever see it. If it
is marked for the client, then the server won't execute it.

That's right, cannot be the same block and client will not see the block
marked for the server. However, both blocks can include same external JS
file.