469,352 Members | 2,026 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,352 developers. It's quick & easy.

is it possible to call vbs file with js?

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?

May 19 '06 #1
11 8588
VK

rgintexas wrote:
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);
....

May 19 '06 #2
VK said the following on 5/19/2006 2:32 AM:
rgintexas wrote:
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 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:

<script type="text/javascript" src="VBFile.vbs">
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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 19 '06 #3
VK

Randy Webb wrote:
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. :-)

May 19 '06 #4
VK said the following on 5/19/2006 3:33 AM:
Randy Webb wrote:
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. :-)


"Unreliable technology pushed by boardroom pundits"

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 19 '06 #5
VK

Randy Webb wrote:
VK said the following on 5/19/2006 3:33 AM:
Randy Webb wrote:
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. :-)


"Unreliable technology pushed by boardroom pundits"


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

May 19 '06 #6
Randy Webb wrote:
VK said the following on 5/19/2006 3:33 AM:
Randy Webb wrote:
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. :-)


"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

May 19 '06 #7
Erwin Moller said the following on 5/19/2006 8:32 AM:
Randy Webb wrote:
VK said the following on 5/19/2006 3:33 AM:
Randy Webb wrote:
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. :-)
"Unreliable technology pushed by boardroom pundits"


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.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 19 '06 #8
Randy Webb wrote:
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
May 20 '06 #9
Roman Ziak said the following on 5/20/2006 7:53 AM:
Randy Webb wrote:
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).


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 21 '06 #10
Erwin Moller wrote:
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
--
#define QUESTION ((bb) || !(bb))
// William Shakespeare (if he would have been a hacker ;-))
May 24 '06 #11
Randy Webb wrote:
Roman Ziak said the following on 5/20/2006 7:53 AM:
Randy Webb wrote:
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).


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.


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.
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.


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.

May 24 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by NickName | last post: by
10 posts views Thread by Frances Del Rio | last post: by
8 posts views Thread by Richard Arthur | last post: by
4 posts views Thread by Tony Cheng | last post: by
9 posts views Thread by Dino Buljubasic | last post: by
5 posts views Thread by veg_all | last post: by
8 posts views Thread by zaheer031 | last post: by
1 post views Thread by CARIGAR | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.