473,320 Members | 1,719 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Generated javascript from .pl files

Hi all,

I'm trying to use some javascript code in Internet Explorer 6.0 that's
being generated by a Perl file. I have a line in my header that looks
something like this:

<script src="jscode.pl?parm1=foo&parm2=monkey" type="text/javascript" /
>
Just for the sake of simplicity, here's a very simplified version of
the Perl code:

print "Content-Type: text/javascript; charset=ISO-8859-1\n\n";
print "alert('Testing, 1-2-3!');\n";
The Perl code returns a header with mime type text/javascript. (I've
tried application/javascript to no avail.) Everything works great in
Firefox, and I get a message box that says "Testing, 1-2-3!" that pops
up when I load the page. However, in Internet Explorer 6.0, even
though the results of pulling up the URL manually looks great, the
code isn't executing. No message box, no errors, no nothing. It's
silently dying.

I think the problem is that Internet Explorer is seeing the .pl
extension and thinking, "Hmm, that's not a Javascript file!" and
bypassing it. It might have something to do with this:
http://msdn2.microsoft.com/en-us/library/ms775148.aspx

Does anyone know if there's anything I can do to get a Perl script to
be read by Internet Explorer as a legitimate javascript file? Is
there something special I have to do on the server (IIS 6.0 on Win2k3
Server)? Or is it just plain not possible?

Aug 7 '07 #1
21 1811
TonyV said the following on 8/7/2007 6:57 PM:
Hi all,

I'm trying to use some javascript code in Internet Explorer 6.0 that's
being generated by a Perl file. I have a line in my header that looks
something like this:

<script src="jscode.pl?parm1=foo&parm2=monkey" type="text/javascript" /

Just for the sake of simplicity, here's a very simplified version of
the Perl code:

print "Content-Type: text/javascript; charset=ISO-8859-1\n\n";
print "alert('Testing, 1-2-3!');\n";
The Perl code returns a header with mime type text/javascript. (I've
tried application/javascript to no avail.) Everything works great in
Firefox, and I get a message box that says "Testing, 1-2-3!" that pops
up when I load the page. However, in Internet Explorer 6.0, even
though the results of pulling up the URL manually looks great, the
code isn't executing. No message box, no errors, no nothing. It's
silently dying.

I think the problem is that Internet Explorer is seeing the .pl
extension and thinking, "Hmm, that's not a Javascript file!" and
bypassing it. It might have something to do with this:
http://msdn2.microsoft.com/en-us/library/ms775148.aspx

Does anyone know if there's anything I can do to get a Perl script to
be read by Internet Explorer as a legitimate javascript file? Is
there something special I have to do on the server (IIS 6.0 on Win2k3
Server)? Or is it just plain not possible?
Can you put up a test page that uses that code that can be tested with
different configurations? I just manually tested IE7 with a .pl
extension and it gave me no problems with an external file.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Aug 7 '07 #2
On Aug 7, 6:57 pm, TonyV <kingskip...@gmail.comwrote:
Hi all,

I'm trying to use some javascript code in Internet Explorer 6.0 that's
being generated by a Perl file. I have a line in my header that looks
something like this:

<script src="jscode.pl?parm1=foo&parm2=monkey" type="text/javascript" /

Just for the sake of simplicity, here's a very simplified version of
the Perl code:

print "Content-Type: text/javascript; charset=ISO-8859-1\n\n";
print "alert('Testing, 1-2-3!');\n";
Wrong MIME type, despite what the type attribute would seem to imply.
The Perl code returns a header with mime type text/javascript. (I've
tried application/javascript to no avail.) Everything works
Try application/x-javascript.

great in
Firefox, and I get a message box that says "Testing, 1-2-3!" that pops
up when I load the page. However, in Internet Explorer 6.0, even
though the results of pulling up the URL manually looks great, the
code isn't executing. No message box, no errors, no nothing. It's
silently dying.

I think the problem is that Internet Explorer is seeing the .pl
extension and thinking, "Hmm, that's not a Javascript file!" and
User agents do not determine MIME types from extensions. URI's are
not file paths anyway. Servers map requested URI's to file paths or
processes and in some cases map file extensions to MIME types for
responses.
bypassing it. It might have something to do with this:http://msdn2.microsoft.com/en-us/library/ms775148.aspx
No.
Does anyone know if there's anything I can do to get a Perl script to
be read by Internet Explorer as a legitimate javascript file? Is
there something special I have to do on the server (IIS 6.0 on Win2k3
Server)? Or is it just plain not possible?
It is quite possible. Looking at your script declaration:

<script src="jscode.pl?parm1=foo&parm2=monkey" type="text/
javascript" /

I assume the tag is closed after the slash, so you should realize that
you cannot use self-closing tags with script elements. Change to:

<script src="jscode.pl?parm1=foo&parm2=monkey" type="text/
javascript"></script>

Fix that and the MIME type and it should work fine. Post a link to a
sample page if not.

Aug 8 '07 #3
TonyV wrote:
I'm trying to use some javascript code in Internet Explorer 6.0 that's
being generated by a Perl file. I have a line in my header that looks
something like this:

<script src="jscode.pl?parm1=foo&parm2=monkey" type="text/javascript" /
------------------------------------------------------------------------^
Just for the sake of simplicity, here's a very simplified version of
the Perl code:

print "Content-Type: text/javascript; charset=ISO-8859-1\n\n";
print "alert('Testing, 1-2-3!');\n";

[...] However, in Internet Explorer 6.0, even
though the results of pulling up the URL manually looks great, the
code isn't executing. No message box, no errors, no nothing. It's
silently dying.

I think the problem is that Internet Explorer is seeing the .pl
extension and thinking, "Hmm, that's not a Javascript file!" and
bypassing it. It might have something to do with this:
http://msdn2.microsoft.com/en-us/library/ms775148.aspx
I find it more likely that your pseudo-XHTML (see the marker above) is
causing the problem. IE does not support X(HT)ML, so the `script' element
does not end. However, if using HTML instead does not solve the problem:
You are not required to serve Perl-generated content as resource with a .pl
suffix; in fact, it is recommended not to do so; use content negotiation
instead (why not .js.pl, and using .js?). [1]
PointedEars
___________
[1] http://www.w3.org/QA/Tips/uri-choose pp., especially
http://www.w3.org/Provider/Style/URI
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Aug 8 '07 #4
Thomas 'PointedEars' Lahn wrote:
TonyV wrote:
><script src="jscode.pl?parm1=foo&parm2=monkey" type="text/javascript"

simplified version of the Perl code:
print "Content-Type: text/javascript; charset=ISO-8859-1\n\n";
print "alert('Testing, 1-2-3!');\n";

[...] However, in Internet Explorer 6.0, even
though the results of pulling up the URL manually looks great, the
code isn't executing. No message box, no errors, no nothing. It's
silently dying.
>I think the problem is that Internet Explorer is seeing the .pl
extension and thinking, "Hmm, that's not a Javascript file!" and
bypassing it. It might have something to do with this:
http://msdn2.microsoft.com/en-us/library/ms775148.aspx

I find it more likely that your pseudo-XHTML (see the marker above) is
causing the problem. IE does not support X(HT)ML, so the `script' element
does not end. However, if using HTML instead does not solve the problem:
You are not required to serve Perl-generated content as resource with a .pl
suffix; in fact, it is recommended not to do so; use content negotiation
instead (why not .js.pl, and using .js?).
I think a better approach here is to alter the .pl extension to .js,
and tell server to execute .js as CGI. It's simple and robust - I use
it a lot.

If you're on *nix, add a file named ".htaccess" in the same directory,
with content:

AddHandler cgi-script .js

This will cause .js files to be executed as (Perl) CGI script, and
output the actual content to the <scriptcall. Then make sure to use
the default "application/x-javascript" MIME type, and no danger for
any browser incompatibility.

--
Bart

Aug 8 '07 #5
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
>You are not required to serve Perl-generated content as resource with a .pl
suffix; in fact, it is recommended not to do so; use content negotiation
instead (why not .js.pl, and using .js?).

I think a better approach here is to alter the .pl extension to .js,
and tell server to execute .js as CGI. It's simple and robust - I use
it a lot.
If you like driving with the handbrake pulled, you might want to do that.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Aug 8 '07 #6
Thomas 'PointedEars' Lahn wrote:
Bart Van der Donck wrote:
>I think a better approach here is to alter the .pl extension to .js,
and tell server to execute .js as CGI. It's simple and robust - I use
it a lot.

If you like driving with the handbrake pulled, you might want to do that.
If this would be a problem, you shouldn't let the file being parsed by
server in the first place. This consumes much more memory than a
htaccess lookup.

Alternatively, you could add the setting in Apache's general conf file
instead of htaccess.

Some systems keep htaccess files in their operating memory, so they
don't need to be re-parsed.

--
Bart

Aug 8 '07 #7
TonyV wrote:
I'm trying to use some javascript code in Internet Explorer 6.0 that's
being generated by a Perl file. I have a line in my header that looks
something like this:

<script src="jscode.pl?parm1=foo&parm2=monkey" type="text/javascript" /

Just for the sake of simplicity, here's a very simplified version of
the Perl code:

print "Content-Type: text/javascript; charset=ISO-8859-1\n\n";
print "alert('Testing, 1-2-3!');\n";

The Perl code returns a header with mime type text/javascript. (I've
tried application/javascript to no avail.) Everything works great in
Firefox, and I get a message box that says "Testing, 1-2-3!" that pops
up when I load the page. However, in Internet Explorer 6.0, even
though the results of pulling up the URL manually looks great, the
code isn't executing. No message box, no errors, no nothing. It's
silently dying.
I've had good experiences by making the .js writable, and put the Perl
program (as non-CGI) in a cronjob, and then periodically rewrite the
content from cronjob into the .js file.

The .js-call then becomes a read-action and not an execute-action,
which dramatically improves performance under heavy conditions (and
especially when database queries are involved).

Of course, the cronjob frequency depends on how often your js data
should be updated.

It's a bit more work, but if you're on a heavy traffic website, I
think you should definitely consider it.

I'm using such a setup for many years and found it an excellent way to
reduce load on that machine.

--
Bart

Aug 8 '07 #8
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
>Bart Van der Donck wrote:
>>I think a better approach here is to alter the .pl extension to .js,
and tell server to execute .js as CGI. It's simple and robust - I use
it a lot.
If you like driving with the handbrake pulled, you might want to do that.

If this would be a problem, you shouldn't let the file being parsed by
server in the first place.
No, it is very inefficient to have the server execute .js as CGI, because
that would apply to *every* .js file. Instead, enabling content negotiation
and having only resources with e.g. suffix .js.pl executed as CGI while they
are accessed with a .js suffix and letting the server "decide" what to do
with it, is much more efficient, flexible (allows for using *any*
server-side language to generate the client-side script code) and easier to
maintain.

Have you followed the URI advisory link in my first followup in this thread?
This consumes much more memory than a htaccess lookup.
And "This" would be what exactly?
Alternatively, you could add the setting in Apache's general conf file
instead of htaccess.

Some systems keep htaccess files in their operating memory, so they
don't need to be re-parsed.
You've lost me. What has .htaccess got to do with it? And, IIUC, how do
you got the idea that content negotation has nothing to do with .htaccess?
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Aug 8 '07 #9
Thomas 'PointedEars' Lahn wrote:
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
Bart Van der Donck wrote:
I think a better approach here is to alter the .pl extension to .js,
and tell server to execute .js as CGI. It's simple and robust - I use
it a lot.
If you like driving with the handbrake pulled, you might want to do that.
If this would be a problem, you shouldn't let the file being parsed by
server in the first place.

No, it is very inefficient to have the server execute .js as CGI, because
that would apply to *every* .js file.
I'm sorry? You can certainly set this for a whole webserver, for a
single directory, or for one file. It wouldn't be too wise to set such
a rule for the whole server indeed.
Instead, enabling content negotiation
and having only resources with e.g. suffix .js.pl executed as CGI while they
are accessed with a .js suffix and letting the server "decide" what to do
with it, is much more efficient, flexible
I don't see where the difference is. You do it for .js.pl (on whole
server, so it seems), and I do it for .js on file/directory base. You
set your httpd.conf/htaccess to output .js.pl as application/x-
javascript, and I tell it to parse .js as CGI, right? Why would yours
be more efficient or flexible then?
(allows for using *any* server-side language to generate the client-side
script code)
And why would that not be the case in my scenario? All I say is that
the js file in question should be parsed as CGI by webserver. It's
just coincidence that Perl is the CGI language in this case. It can be
anything. Even more: when you write your rule for .js.pl, you at least
*suggest* Perl is the language, while my solution doesn't suggest
anything about that.
and easier to maintain.
In our both scenarios, only one config line is to be maintained.
Maintainance is identical.
This consumes much more memory than a htaccess lookup.

And "This" would be what exactly?
This = parsing a CGI programme that's written in Perl. Apache must
load the code into memory, pass it to the Perl executable, gets back
compiled result and outputs it to client. This process requires more
memory than a single htaccess lookup.
Alternatively, you could add the setting in Apache's general conf file
instead of htaccess.
Some systems keep htaccess files in their operating memory, so they
don't need to be re-parsed.

You've lost me. What has .htaccess got to do with it?
So that the same .htaccess file does not need to be loaded again for
every new request (as long as it doesn't change, of course). This
"buffer" causes less load for Apache (it holds the directives for the
file "ready"), though I'ld say you'll only see a noticeable impact on
heavy traffic websites.
And, IIUC, how do you got the idea that content negotation has nothing
to do with .htaccess?
Well, uhm, what about, I didn't have that idea? :) Of course they are
related.

--
Bart

Aug 8 '07 #10
A short update:

I'm sorry for the confusion, I'm unfortunately not using Apache, the
server is IIS 6.0. (I'm not being facetious; I normally use a LAMP
setup which is why I'm a little out of my league on this one.)

I tried replacing the <script ... /with <script ...></scriptand I
got the same results. I haven't tried changing the MIME type from
text/javascript to application/x-javascript yet, that's what I'm going
to do now and I'll post the results.

I'd rather avoid giving Perl files .js extension if possible to avoid
confusion server-side. I'm not the only one who's writing scripts for
that server. .js.pl is a possibility (and the more I think about it,
a really good idea!), but it seems to me that trying to retrieve a
file with a .js.pl extension wouldn't be functionally different than
retrieving one with a .pl extension.

At any rate, I'm off to try changing the MIME type and see what
happens. Thanks for the help, I'll post again when I have more info.

-KS

Aug 8 '07 #11
TonyV wrote:
[...] I'm unfortunately not using Apache, the server is IIS 6.0. [...]
IIS 6.0 supports Content Negotiation, too. Requires a bit of tweaking, though.

http://www.websiteoptimization.com/speed/tweak/rewrite/
I tried replacing the <script ... /with <script ...></scriptand I
got the same results. I haven't tried changing the MIME type from
text/javascript to application/x-javascript yet, that's what I'm going
to do now and I'll post the results.
It would be not Valid markup if you changed the media type from one
registered and fully supported, albeit marked deprecated recently, to one
being experimental or in other words proprietary. Especially with HTTP, it
probably breaks interoperability in the long-term.
[...] .js.pl is a possibility (and the more I think about it,
a really good idea!), but it seems to me that trying to retrieve a
file with a .js.pl extension wouldn't be functionally different than
retrieving one with a .pl extension.
It would, because you would use only .js in the request and let the server
see about which .js.suffix file matches that. And the only thing that you
would need to change over time is the server configuration that says how
..suffix (here .pl) is to be handled. Yes, Content Negotiation *is* a
*really* *good* idea; I'm glad it does exist.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Aug 8 '07 #12
Thomas 'PointedEars' Lahn wrote:
TonyV wrote:
>[...] .js.pl is a possibility (and the more I think about it,
a really good idea!), but it seems to me that trying to retrieve a
file with a .js.pl extension wouldn't be functionally different than
retrieving one with a .pl extension.

It would, because you would use only .js in the request
Yes, always.
and let the server see about which .js.suffix file matches that.
This is where I'm lost.
And the only thing that you would need to change over time is the
server configuration that says how .suffix (here .pl) is to be
handled.
Could you show the relevant httpd.conf lines how you would achieve
this ?

Thanks

--
Bart

Aug 8 '07 #13
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
>TonyV wrote:
>>[...] .js.pl is a possibility (and the more I think about it,
a really good idea!), but it seems to me that trying to retrieve a
file with a .js.pl extension wouldn't be functionally different than
retrieving one with a .pl extension.
It would, because you would use only .js in the request
[...]
>and let the server see about which .js.suffix file matches that.

This is where I'm lost.
>And the only thing that you would need to change over time is the
server configuration that says how .suffix (here .pl) is to be
handled.

Could you show the relevant httpd.conf lines how you would achieve
this ?
In its most simple form,

Options +MultiViews
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Aug 8 '07 #14
Thomas 'PointedEars' Lahn wrote:
Bart Van der Donck wrote:
>Thomas 'PointedEars' Lahn wrote:
>>And the only thing that you would need to change over time is the
server configuration that says how .suffix (here .pl) is to be
handled.
>Could you show the relevant httpd.conf lines how you would achieve
this ?

In its most simple form,

Options +MultiViews
I see. I wasn't aware of that technique. But I doubt it's the best
here. For the OP's question, I would still councel to use

AddHandler cgi-script .js

in a specific directory holding his perl-generated javascript files.

--
Bart

Aug 8 '07 #15
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
>Bart Van der Donck wrote:
>>Thomas 'PointedEars' Lahn wrote:
And the only thing that you would need to change over time is the
server configuration that says how .suffix (here .pl) is to be
handled.
Could you show the relevant httpd.conf lines how you would achieve
this ?
In its most simple form,

Options +MultiViews

I see. I wasn't aware of that technique.
Now come on, how many times have I written "Content Negotiation" already?
But I doubt it's the best here.
If you deem a technique to be not the best as a solution to a problem, you
would have to come up with an alternative that is objectively a better one,
i.e. has a considerable benefit over the former, or such a statement stands
and falls with your credibility among your readers.

I have been using Content Negotiation for years now. It works just fine,
even with Apache 1.x; it gives me little to no headache, and the performance
loss for the additional lookup really is insignificant. For example, do you
think I am updating the date of modification in [1] *manually* or that there
even exists an "es-matrix" directory? Do you think that I am using any
programming to determine what translation should be used automatically
according to the users preferences in [2]? I could go on, but it would be
better if you read the (Apache) docs on how CN automagically can work for you.

[1] http://pointedears.de/scripts/es-matrix
[2] http://pointedears.de/scripts/test/whatami
For the OP's question, I would still councel to use

AddHandler cgi-script .js

in a specific directory holding his perl-generated javascript files.
That would impose an unnecessary restriction, where

AddHandler cgi-script .pl
Options +MultiView

would not. So in what way would the former be better, please?
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Aug 8 '07 #16
Thomas 'PointedEars' Lahn wrote:
[...]
You bring up new unrelated matters to the discussion that have nothing
to do with javascript nor with the original topic. If you want to
discuss HTTP, this is not the place for that.

You have proposed your solution, and I have proposed mine, and I gave
you 5 good reasons why mine was better.

Last word is for you.

--
Bart

Aug 9 '07 #17
Thomas 'PointedEars' Lahn wrote:
[...]
You bring up new unrelated matters to the discussion that have nothing
to do with javascript nor with the original topic. If you want to
discuss HTTP, this is not the place for that.

You have proposed your solution, and I have proposed mine, and I gave
you 5 good reasons why mine was better.

Last word is for you.

--
Bart

Aug 9 '07 #18
Thomas 'PointedEars' Lahn wrote:
[...]
You bring up new unrelated matters to the discussion that have nothing
to do with javascript nor with the original topic. If you want to
discuss HTTP, this is not the place for that.

You have proposed your solution, and I have proposed mine, and I gave
you 5 good reasons why mine was better.

Last word is for you.

--
Bart

Aug 9 '07 #19
Thomas 'PointedEars' Lahn wrote:
[...]
You bring up new unrelated matters to the discussion that have nothing
to do with javascript nor with the original topic. If you want to
discuss HTTP, this is not the place for that.

You have proposed your solution, and I have proposed mine, and I gave
you 5 good reasons why mine was better.

Last word is for you.

--
Bart

Aug 9 '07 #20
Thomas 'PointedEars' Lahn wrote:
[...]
You bring up new unrelated matters to the discussion that have nothing
to do with javascript nor with the original topic. If you want to
discuss HTTP, this is not the place for that.

You have proposed your solution, and I have proposed mine, and I gave
you 5 good reasons why mine was better.

Last word is for you.

--
Bart

Aug 9 '07 #21
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
>[...]
(sic!)

What good is this quotation for?
You bring up new unrelated matters to the discussion that have nothing
to do with javascript nor with the original topic. [...]
IBTD, I did no such thing. What happened was: The OP asked for a solution
to his problem, and I have provided one. You have then debated that my
solution is one, but I have explained why it is one. And then:
If you want to discuss HTTP, this is not the place for that.
You must be kidding. *You* diverted to a discussion about HTTP, although
HTTP headers have exactly *nothing* to do with my solution. (How many times
have I been trying to explain that to you now? I lost count.)
You have proposed your solution, and I have proposed mine, and I gave
you 5 good reasons why mine was better.
IMNSHO, I have successfully refuted all of your "good reasons"; they *may*
be good reasons for not using CN in general (I did not debate, nor did I
confirm that), but they are *not* good reasons for not using CN *for this
particular problem*, because the explanations given refer to situations that
simply *don't apply* here (again, *no HTTP Content-* headers are involved in
my solution!*).

I'm sorry you can't see that.
Last word is for you.
[x] done
HAND

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml$
-- Bjoern Hoehrmann
Aug 9 '07 #22

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
by: Akbar | last post by:
Hey there, Big-time curiosity issue here... Here's the test code (it's not that long)... it's to display a large number of image links with captions, ideally pulled in from an external file...
12
by: HarveyB | last post by:
I would like to generate non-modal popup windows from ASP.Net code-behind. I have tried using Client Side scripting like "function Test(){ window.open('test.htm',_blank,...
1
by: cirillo_curiosone | last post by:
Hi, i'm new to javascript. I started studing it on the web few weeks ago, but still haven't been able to solve one big problem: HOT TO PASS VALUES FROM A SCRIPT VARIABLE TO A CHILD HTML...
6
by: Alan Krueger | last post by:
Is there a way to automatically include C# files (.cs) generated by a third-party tool into a Visual C# .NET build? It's possible the set of files generated by this tool might change. Adding...
0
by: Jim Corey | last post by:
I'm experimenting with a code generator that creates an html page which includes a lot of javascript that modifies (for example) input boxes on the page. I can paste the html into an aspx page,...
3
by: Nathan Gilbert | last post by:
I am wanting to use javascript to select between different *.css files dependent on the user's browser. I am also wanting to generate the html document containing this javascript dynamically using...
1
by: Dave | last post by:
I have "header.html" used by PERL to construct an entire page. Unfortunately, this header page contains no head or body tags; the script generates them. So I am at a loss as to how I can reference...
3
by: Arpan | last post by:
Web Services make use of proxy classes whose methods & properties are accessed in exactly the same way as how a normal class' methods & properties are accessed. So what for does ASP.NET generate...
2
by: HopfZ | last post by:
Server sends cookie to browser and the browser send the same cookie back to the server according to Wikipedia. Do browsers send even javascript-generated cookie to servers? For example, if I...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.