Re: Controlling Javascript from server side

Thomas 'PointedEars' Lahn wrote:

Bart Van der Donck wrote:

#!/usr/bin/env python
print "Content-type: text/html\n\n"

The "Content-Type" header value of a HTTP message should always contain a
declaration of the encoding of the message body ("charset=...").

And in absence of which, the expected encoding is always ISO/IEC
8859-1, being the default HTTP charset ever since. It's not widely
used to set a character set here, unless, of course, you want
something else than ISO/IEC 8859-1. But it's not a bad habit nowadays
to add it anyhow, especially in regard to the growing Unicode support
and further internationalization of the internet.

A javascript programme:
[ snip code ]

It is merely ECMAScript-3-conforming code, or such a script or program.

Then I suggest we rename this group to 'comp.lang.ECMAScript-3-
conforming-code'.

It may seem like nitpicking, but it is very important to understand that
whether it is JavaScript or not is defined by the execution environment,
that is the ECMAScript *implementation*, the script engine that is used
to execute the code. For example, it would be Netscape JavaScript in NN2+
and Gecko-based UAs, Microsoft JScript in MSHTML (IE-based), Opera
ECMAScript in Opera, KJS ECMAScript in Konqueror, and JavaScriptCore
JavaScript in Safari. (Hence my use of the terms "J(ava)Script/ECMAScript"
or "JS/ES".)

I am aware that different browers have different js engines, yes.

var _global = this;

function ajax(url, vars, callbackFunction) {
if (window.XMLHttpRequest) {

Wrong feature test. Should be:

if (/\b(function|object)\b/i.test(typeof XMLHttpRequest)
&& _global.XMLHttpRequest)

Code for the lab.

var request = new XMLHttpRequest();

One wants to attempt exception handling here in the case this fails anyway.

I haven't seen any advisories that recommend it on this place.

var request = new ActiveXObject('MSXML2.XMLHTTP.3.0');

Contrary to what the MSDN Library says, it is not necessary here to force a
specific (the newest) version of MSXML or IXMLHTTPRequest; all used
properties are available ever since. The required exception handling should
be added in the case this fails.

The inner working of MSXML is not accessible, so I follow the
guidelines recommended by Microsoft in their documentation. Seems a
reasonable approach to me.

request.open('GET', url, true);

AFAIK the third argument is unnecessary here, although may be used to
indicate the default value (`true').

'true' means that the request must be handled asynchronously. Makes
sense to me to set it here explicitly for code clarity that we want
async here and not sync (even when 'true' would be the default).

request.setRequestHeader('Content-Type', '');

That would make the HTTP request invalid,

No, the request will still be valid.

as the header name "Content-Type" is inappropriate at least for a *GET*
request. (HTTP/1.x does not define such a request header for any request
type, only a response header.[1]

It doesn't matter. If you use a header like...

abc: 123

....it would still remain a valid request. The most you can say, is
that the receiver doesn't do anything with this information. Receiver
might ignore or not understand the line, but that never affects the
(in)validity of the request as a whole. You're correct that a false
impression may be created here (as if the query string were offered as
text/html or something, while it is always one ASCII percent-endoded
string).

[CMIIW] However, to submit different types of information on POST requests,
HTML 4.01 specified implicitly that the Content-Type header may be used also
for request messages. The default used for submitting forms with POST is
specified as "application/x-www-form-urlencoded" which usually suffices.[2]

True, and that's exactly why it can be left empty in my code. No need
to write every <form> as <form enctype="application/x-www-form-
urlencoded"> neither.

It is not used by the interface for GET; those requests have no Content-Type
header by default.)

And, more important, the header value must not be empty. The interface does
not specify a default value to be used when the second parameter is the
empty string.

That method call in general will also throw an exception with some builds,
IIRC of Opera.

[1]http://www.rfc-editor.org/rfc/rfc1945.txt
http://www.rfc-editor.org/rfc/rfc2616.txt
[2]http://www.w3.org/TR/html401/interact/forms.html#form-content-type

request.onreadystatechange = function() {
if (request.readyState == 4 && request.status == 200) {

Other final response status codes than `200' are possible for a successful
request, see HTTP/1.x and the interface specification.

Depends on what resource is requested. Code 200 will be okay in
default uses of XMLHttpRequest, unless, of course, you want something
else.

if (request.responseText) {

That test would only handle the case (and improve efficiency a bit with the
code below) if the response body would be empty. It can be safely omitted.

I suppose it's quite possible that the body of the response would be
empty, like for instance a database that's not reachable. And what
about feature testing ?

document.getElementById('myField').value =

Missing feature test, therefore error-prone referencing.

Of course the programmer must create an element with ID 'myField'. Of
course the programmer supposes that 'getElementById' is supported by
the client. Do you really believe that it's necessary to feature-test
on all these elementary things ? I don't.

(request.responseText).replace(/(\r\n|\r|\n|\s)/g, '');

There is no need for parantheses around the object reference, and the
Regular Expression can be written more efficient (matching the same characters):

... = request.responseText.replace(/\s+/g, '');

Correct.

request.send(vars);

This assumes a POST request where the argument of IXMLHTTPRequest::send()
specifies the message body. However, that is not the case here (it's GET),
so the value should be `undefined' (i.e. not passed at all), or `null' to be
compatible to the Gecko DOM. That decision should not be left to the caller
of ajax().

'send()' is better when using GET.

// perform new call every 2 seconds (2000 milliseconds)
setTimeout("ajax('file.py?' + Math.random(), '', '')", 2000);
}
document.write('Status value: <input type="text" id="myField">');

If a `form' element would be written here that contained the `input'
element, the feature test for D::gEBI() above would be unnecessary.

Naturally, it's the intention that the original poster will not only
use <input>, but makes a total webpage with <form>, <html>, <body>
etc.

ajax('file.py?' + Math.random(), '', '');

Given the nature of random numbers in general, and especially
machine-generated random numbers, this will not avoid a cached
resource to be retrieved, which was probably the intention.
The following would:

ajax('file.py?' + (new Date()).getTime(), '', '');

That is conceptually better, yes. But any idea about which scale we're
talking here ? Math.random() gives me 15 to 18 digits after comma,
let's say 16 for easy calculation. A user would have 1 chance out of
10.000.000.000.000.000 that the next value is the same. With a 2
second refresh, the scope is 634.195.839 years. The difference is in
the head.

--
Bart

.

Relevant Pages