Generic innerHTML functionality and other minor questions...

[Luke Matuszewski]

Welcome
I have read the in the faq from jibbering about the generic
DynWrite, but i also realized that is uses only innerHTML feature of
HTML objects.
(1) Is there a DOM function which is very similar to innerHTML property
eg. (my guess) setInnerNodeAsText or sth... ?

I want to write function which will be dynamically updateing some of my
select boxes. My question is:
(2.1) Can i use innerHTML property of SELECT (or even incorporate
DynWrite function) and in such form update some selects boxes on some
event ? (i ask because i saw the way which uses Option object, and
assumed is it not as portable as innerHTML solution).

(2.2) Should i use XmlHttpRequest object (and it equivalent in IE from
ActiveX - in the same way as it is used in Beta Google search site) or
i must consider using something like jsrs:
http://www.ashleyit.com/rs/main.htm (but i saw it uses browser sniffing
in a way of testing objects like document.all or document.layers which
in my opinion should not be this way - the best is to use object
detection system).

(3) Does anyone know a project which beautifies harshed JavaScript code
(like as.js from mentioned above beta google site which uses browser
independent autocomplete solution for text boxes).

(4) I have heard about 'this' keyword troubles, so generally my
question is - do i have to use eg
funtion MyConstructor() {
var myRef = this;
this.myMethod = function() {
/* use myRef instead of keyword 'this' */
}
}

MyConstructor.myStaticPublicMethod() { /* method tied up to
MyConstructor function object */
var myRef = this;
/* use myRef instead of keyword 'this' */
}

I think thats all my questions, would be appreciate for answer (i tried
to make this post as legible as i could).
BR
Luke M.

 

[Joshie Surber]

(1) Is there a DOM function which is very similar to innerHTML property

No, you have to create each element yourself.

(2.1) Can i use innerHTML property of SELECT (or even incorporate
DynWrite function) and in such form update some selects boxes on some
event ? (i ask because i saw the way which uses Option object, and
assumed is it not as portable as innerHTML solution).

The Option object and innerHTML are both portable, implemented by
almost every browser. The option object predates innerHTML by a year or
two, but they are both used in every JS browser implementation that I
have heard of.

(2.2) Should i use XmlHttpRequest object (and it equivalent in IE from
ActiveX - in the same way as it is used in Beta Google search site) or
i must consider using something like jsrs:
http://www.ashleyit.com/rs/main.htm (but i saw it uses browser sniffing
in a way of testing objects like document.all or document.layers which
in my opinion should not be this way - the best is to use object
detection system).

I would use XMLHTTPObject simply because it is pretty much the same
everywhere (once you have created the object.)

(3) Does anyone know a project which beautifies harshed JavaScript code
(like as.js from mentioned above beta google site which uses browser
independent autocomplete solution for text boxes).

Run it thru indent(1) then run a few :%s/gvar/realVarName/g filters on
it in VIM.

(4) I have heard about 'this' keyword troubles, so generally my
question is - do i have to use eg
funtion MyConstructor() {
var myRef = this;
this.myMethod = function() {
/* use myRef instead of keyword 'this' */
}
}

MyConstructor.myStaticPublicMethod() { /* method tied up to
MyConstructor function object */
var myRef = this;
/* use myRef instead of keyword 'this' */
}

Neither... "this" is the instance of the function that calls it. For
example, if your constructor was called thus: newObject = new
MyConstructor();
then newObject.this == newObject. this is most useful for passing
objects as arguments; for example, using a form validator, you may use
<form onsubmit="validate(this)"> and then your validation function
could read
function validate(f) {
firstFormElement = f.elements[0];
...
}

 

[Joshie Surber]

(1) Is there a DOM function which is very similar to innerHTML property

No, you have to create each element yourself.

(2.1) Can i use innerHTML property of SELECT (or even incorporate
DynWrite function) and in such form update some selects boxes on some
event ? (i ask because i saw the way which uses Option object, and
assumed is it not as portable as innerHTML solution).

The Option object and innerHTML are both portable, implemented by
almost every browser. The option object predates innerHTML by a year or
two, but they are both used in every JS browser implementation that I
have heard of.

(2.2) Should i use XmlHttpRequest object (and it equivalent in IE from
ActiveX - in the same way as it is used in Beta Google search site) or
i must consider using something like jsrs:
http://www.ashleyit.com/rs/main.htm (but i saw it uses browser sniffing
in a way of testing objects like document.all or document.layers which
in my opinion should not be this way - the best is to use object
detection system).

I would use XMLHTTPObject simply because it is pretty much the same
everywhere (once you have created the object.)

(3) Does anyone know a project which beautifies harshed JavaScript code
(like as.js from mentioned above beta google site which uses browser
independent autocomplete solution for text boxes).

Run it thru indent(1) then run a few :%s/gvar/realVarName/g filters on
it in VIM.

(4) I have heard about 'this' keyword troubles, so generally my
question is - do i have to use eg
funtion MyConstructor() {
var myRef = this;
this.myMethod = function() {
/* use myRef instead of keyword 'this' */
}
}

MyConstructor.myStaticPublicMethod() { /* method tied up to
MyConstructor function object */
var myRef = this;
/* use myRef instead of keyword 'this' */
}

Neither... "this" is the instance of the function that calls it. For
example, if your constructor was called thus: newObject = new
MyConstructor();
then newObject.this == newObject. this is most useful for passing
objects as arguments; for example, using a form validator, you may use
<form onsubmit="validate(this)"> and then your validation function
could read
function validate(f) {
firstFormElement = f.elements[0];
...
}

 

[Michael Winter]

On 22/11/2005 08:55, Luke Matuszewski wrote:

[snip]

(1) Is there a DOM function which is very similar to innerHTML
property eg. (my guess) setInnerNodeAsText or sth... ?

There is no way to pass a string containing HTML and have it parsed and
inserted into the document tree. However, text nodes are represented.
For example,

<p id="myP">Some <em>emphasised</em> text.</p>

would create the following structure:

p (element)
+- 'Some ' (#text)
+- em (element)
| +- 'emphasised' (#text)
+- ' text.' (#text)

Text nodes have a data property and this can be modified:

var p = document.getElementById('myP'),
text = p.firstChild;

text.data = 'Some different ';

resulting in the equivalent of:

<p id="myP">Some different <em>emphasised</em> text.</p>

It's also possible to create additional text nodes, using the
document.createTextNode method.

[snip]

(2.1) Can i use innerHTML property of SELECT (or even incorporate
DynWrite function) and in such form update some selects boxes on some
event ?

Undoubtedly, but it's unlikely that I'd use it. Then again, you haven't
explained what you're trying to do.

(i ask because i saw the way which uses Option object, and assumed is
it not as portable as innerHTML solution).

On the contrary. Using the innerHTML property is less portable.

The Option constructor is a de facto function originating from NN4, and
has gathered quite widespread support. Though W3C DOM methods can take
its place, the Option constructor is still preferred by some due to
greater support.

(2.2) Should i use XmlHttpRequest object [...] or i must consider
using something like jsrs:

To do what? You really should stop asking questions without stating the
purpose behind them.

[snip]

(4) I have heard about 'this' keyword troubles, [...]

Did you actually read the follow-ups I posted to your previous threads?
There are /no/ 'troubles'.

[snip]

Mike

 

[VK]

(4) I have heard about 'this' keyword troubles, [...]

Did you actually read the follow-ups I posted to your previous threads?
There are /no/ 'troubles'.

He's mentioning the recently discussed issue with broken
(non-canonical) "this" context behavior in inner object classes. It is
well analysed here:
<http://www.crockford.com/javascript/private.html>
(Look for "workaround for an error in the ECMAScript Language
Specification which causes this to be set incorrectly for inner
functions").

 

[VK]

"this" context behavior in inner object classes

"this" context behavior in inner object *methods*

I'm getting again lexdyslic ...damn... dyslexic

 

[Michael Winter]

On 22/11/2005 10:02, Joshie Surber wrote:

[snip]

[...] "this" is the instance of the function that calls it.

Presumably that's a typo. If not, it's completely incorrect and I refer
you to a recent post of mine; another follow-up to Luke, as it happens.

Subject: Object oriented stuff and browsers related thing
Date: 2005-11-20 00:05
Message-Id: [email protected]

<http://groups.google.co.uk/group/co...cb64c504859/1edf3029a9bed649#1edf3029a9bed649>

Specifically the part that begins, "The value of the this operator...".

[snip]

Mike

 

[Luke Matuszewski]

Michael Winter napisal(a):

On 22/11/2005 08:55, Luke Matuszewski wrote:

(2.1) Can i use innerHTML property of SELECT (or even incorporate
DynWrite function) and in such form update some selects boxes on some
event ?

Undoubtedly, but it's unlikely that I'd use it. Then again, you haven't
explained what you're trying to do.

The Option constructor is a de facto function originating from NN4, and
has gathered quite widespread support. Though W3C DOM methods can take
its place, the Option constructor is still preferred by some due to
greater support.

(2.2) Should i use XmlHttpRequest object [...] or i must consider
using something like jsrs:

To do what? You really should stop asking questions without stating the
purpose behind them.

I would like to have a page with few <select> elements in form. When
one select changes its selected value i would like to make a request to
the server CGI (Struts Action Object or PHP script or other CGI system
based program) with an request parameter which would be the value
selected by the user (so it would be probably by onchange event in
select element)
(sample code)
/* x is a reference to XmlHttpRequest */
/* 'this' is a reference to the <select> element <select ...
onchange="MakeRequest(this)" */
function getMyXmlHttpRequestObject() {
var x = null;
try {
x=new ActiveXObject("Msxml2.XMLHTTP")
} catch(e) {
try {
x=new ActiveXObject("Microsoft.XMLHTTP")
} catch(sc) {
x=null
}
}
if( !x && typeof XMLHttpRequest != "undefined") {
x=new XMLHttpRequest()
}
return x;
}

function MakeRequest(selectElem) {
var x = getMyXmlHttpRequestObject();
if(x) {
x.onreadystatechange = changeOptionsInAllSelect(selectElem.form,
x);
/* [1] */
x.open("GET", "/bw/My_Strust_Action/SelectChanged.do?"+
selectElem.name+"="+

selectElem.options[selectElem.selectedIndex].value, true);
x.send(null);
/* [2] */
/* or via POST
x.open("POST", "/bw/My_Strust_Action/SelectChanged.do", true);
x.send(selectElem.name+"="+
selectElem.options[selectElem.selectedIndex].value);
*/
}

function changeOptionsInAllSelect(thisForm, x) {
if( x.readyState == 4 && x.status == 200 ) {

var myXmlData = x.responseXml;
/* make changes... */
}

}

While i was in my University i realized that i really have to ask one
more question:

(1) When i send a request parameter via XmlHttpRequest object which
encoding of request parameter value would be used when sending eg.

1. (if the above script is on the page which was served in Content-Type
as text/html and with charset UTF-8, furthermore the <meta> element
with Content-Type suggest that charset is UTF-8)
The encoding of request parameter send (value of selected element) is
UTF-8.

2. (if the above script is included on the page (via pointing it with
src attrubute in <script> element and the charset attribute is set to
UTF-8) and the page was served in Content-Type as text/html and with
charset UTF-8, furthermore the <meta> is <meta
http-equiv="content-type" content="text/html; charset=UTF-8">)
[2] what encoding would be used if i will send the DOM object and how
it is sended then (in XML?).

 

[Luke Matuszewski]

Michael Winter napisal(a):

On 22/11/2005 08:55, Luke Matuszewski wrote:

(2.1) Can i use innerHTML property of SELECT (or even incorporate
DynWrite function) and in such form update some selects boxes on some
event ?

Undoubtedly, but it's unlikely that I'd use it. Then again, you haven't
explained what you're trying to do.

The Option constructor is a de facto function originating from NN4, and
has gathered quite widespread support. Though W3C DOM methods can take
its place, the Option constructor is still preferred by some due to
greater support.

(2.2) Should i use XmlHttpRequest object [...] or i must consider
using something like jsrs:

To do what? You really should stop asking questions without stating the
purpose behind them.

I would like to have a page with few <select> elements in form. When
one select changes its selected value i would like to make a request to
the server CGI (Struts Action Object or PHP script or other CGI system
based program) with an request parameter which would be the value
selected by the user (so it would be probably by onchange event in
select element)
(sample code)
/* x is a reference to XmlHttpRequest */
/* 'this' is a reference to the <select> element <select ...
onchange="MakeRequest(this)" */
function getMyXmlHttpRequestObject() {
var x = null;
try {
x=new ActiveXObject("Msxml2.XMLHTTP")
} catch(e) {
try {
x=new ActiveXObject("Microsoft.XMLHTTP")
} catch(sc) {
x=null
}
}
if( !x && typeof XMLHttpRequest != "undefined") {
x=new XMLHttpRequest()
}
return x;
}

function MakeRequest(selectElem) {
var x = getMyXmlHttpRequestObject();
if(x) {
x.onreadystatechange = changeOptionsInAllSelect(selectElem.form,
x);
/* [1] */
x.open("GET", "/bw/My_Strust_Action/SelectChanged.do?"+
selectElem.name+"="+

selectElem.options[selectElem.selectedIndex].value, true);
x.send(null);
/* [2] */
/* or via POST
x.open("POST", "/bw/My_Strust_Action/SelectChanged.do", true);
x.send(selectElem.name+"="+
selectElem.options[selectElem.selectedIndex].value);
*/
}

function changeOptionsInAllSelect(thisForm, x) {
if( x.readyState == 4 && x.status == 200 ) {

var myXmlData = x.responseXml;
/* make changes... */
}

}

While i was in my University i realized that i really have to ask one
more question:

(1) When i send a request parameter via XmlHttpRequest object which
encoding of request parameter value would be used when sending eg.

1. (if the above script is on the page which was served in Content-Type
as text/html and with charset UTF-8, furthermore the <meta> element
with Content-Type suggest that charset is UTF-8)
The encoding of request parameter send (value of selected element) is
UTF-8.

2. (if the above script is included on the page (via pointing it with
src attrubute in <script> element and the charset attribute is set to
UTF-8) and the page was served in Content-Type as text/html and with
charset UTF-8, furthermore the <meta> is <meta
http-equiv="content-type" content="text/html; charset=UTF-8">)
[2] what encoding would be used if i will send the DOM object and how
it is sended then (in XML?).

 

[Luke Matuszewski]

I ask this questions about encoding because in most kind of browsers
the request parameters are encoded in the same encoding as the encoding
of the page served. But i don't really know what encoding will be used
when serving paramteres in XmlHttpRequest (or i should use aleready
escaped version of url in open (or send if POST) function call on
object x.

 

[VK]

I ask this questions about encoding because in most kind of browsers
the request parameters are encoded in the same encoding as the encoding
of the page served. But i don't really know what encoding will be used
when serving paramteres in XmlHttpRequest (or i should use aleready
escaped version of url in open (or send if POST) function call on
object x.

The best answer to such questions is *experiment*. Create a testcase
and pass it through the spelled conditions on different browsers. See
if any consistency (which is not guaranteed at all as XMLHttpRequest as
a rather new addon implemented differently by different producers). If
any interesting results - or results at all - do not hesitate to post
them here! ;-)

 

[Luke Matuszewski]

As a final note i realized that i can encode the parameter names and
its values via encode() function - so if i will pass something like
that
x.open("GET",
"/bw/My_Strust_Action/SelectChanged.do?"+escape(selectElem.name+"="+

selectElem.options[selectElem.selectedIndex].value), true);
/* and further more if i know that the value and name property is taken
from my <select> element used on a page with UTF-8 encoding then it
should be escaped due to that encoding so eg latin characters like
polish l and a line crossing it would be encoded as %C5%82 for UTF-8
and %B3 in Windows-1250 encoding).

Does my assumptions are right ?

 

[VK]

As a final note i realized that i can encode the parameter names and
its values via encode() function - so if i will pass something like
that
x.open("GET",
"/bw/My_Strust_Action/SelectChanged.do?"+escape(selectElem.name+"="+

selectElem.options[selectElem.selectedIndex].value), true);
/* and further more if i know that the value and name property is taken
from my <select> element used on a page with UTF-8 encoding then it
should be escaped due to that encoding so eg latin characters like
polish l and a line crossing it would be encoded as %C5%82 for UTF-8
and %B3 in Windows-1250 encoding).

Does my assumptions are right ?

Not exactly.

1) As I explained before UTF-8 is a *transport encoding* thus UTF-8
char sequences are existing only during their travel time from server
to browser and from browser to server. At the moment you are able to
operate with strings using JavaScript, UTF-8 mission is already
completed and all char sequences are converted to the relevant Unicode
chars. So you never need to bother with UTF-8 transformations unless
you decided to emulate an HTTP server using JavaScript.

2) escape / unescape methods are working only with ASCII characters.
For Unicode transformations you have to use encodeURIComponent /
decodeURIComponent methods.

 

[Luke Matuszewski]

When a user inputs some text in the form field it uses it's default
charset set by operating system, but those values inputed by user are
then transformed to encoding specified via Content-Type header in HTTP
response eg. Content-Type: text/html; charset=windows1250 (so it is the
charset used for displaying the page on browser window and for
interpretation by browser - so it now knows what charset to use while
'decoding' the page contents for proper character recognition and then
displaying it (so polish l and a line crossing it would be encoded as
%C5%82 when charset=UTF-8 (takes 2 bytes) and %B3 when
charset=Windows-1250 encoding (takes only one byte).
Inputed values by user in form fields when submit action occurs are
then sent via POST or GET ... When it is POST then it is send in the
Message Body of the HTTP Request using the encoding specified in
mentioned above Content-Type. So HTTP Request looks like that:
[Browser makes HTTP Request via POST]
POST /bw/My_Strust_Action/SelectChanged.do HTTP/1.1
Content-Type: application/x-www-form-urlencoded charset=UTF-8 (or
windows-1250/other)

my_param_name=my_param_value&my_param_name1=my_param_value2

or

[Browser makes HTTP Request via GET (params and values are sent escaped
in URL part)]
GET
/bw/My_Strust_Action/SelectChanged.do?escaped_param_name=escaped_param_value&escaped_param_name1=escaped_param_value2
HTTP/1.1
Content-Type: application/x-www-form-urlencoded charset=UTF-8 (or
windows-1250/other)

To be more precise you must read
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4 (and
specified RFC docs).

Then at the server side - program which parses parameters and its
values can properly decode them because it knows the encoding of
parameters (at first it tries to replace %xx parts to its orginal
form).

Perhaps the biggest difference between the encodeURI() and escape()
functions (and their
decodeURI() and unescape() counterparts) is that the more modern
versions do not encode
a wide range of symbols that are perfectly acceptable as URI characters
according to the syntax
recommended in RFC2396 (http://www.ietf.org/rfc/rfc2396.txt). Thus, the
following
characters are not encoded via the encodeURI() function:
; / ? : @ & = + $ , - _ . ! ~ * ' ( ) #
Use the encodeURI() and decodeURI() functions only on complete URIs.
Applicable URIs can
be relative or absolute, but these two functions are wired especially
so symbols that are part
of the protocol //), search string (? and =, for instance), and
directory-level delimiters (/)
are not encoded.
But as i assumed the string inside those functions is treated as
Unicode string so polish l and a line crossing it would be encoded as
%C5%82, and therefore the values and its names will be sent in Unicode
escaped version.

 

[Luke Matuszewski]

It is true that escape() function produces %u0142 for polish l with a
line crossing readed from field by
forms["myForm"].elements["myFormField"].value (not as is should, but
escape was introduced probably only for US-ASCII characters). encodeURI
or encodeURIComponent() works very well and producing %C5%82. It
happens everytime no matter what charset in Content-Type of HTTP
response was used.
(becouse every string in JavaScript is in Unicode format - even
forms["myForm"].elements["myFormField"].value string).

Then it is wise to write/serve pages in UTF-8 when we want to make play
with i18n. Then at server side treat request params and its values as
UTF-8 strings.

Anyway if open() function of XmlHttpRequest does not produces escape
mechanism for given URL (and probably containing parameters) it is best
to use encodeURI on given URL or encodeURIComponent on URL fragment and
at server side treat reqest param values and its names as encoded in
UTF-8.

ECMAScript v1 defines string as is the set of all finite ordered
sequences of zero or more Unicode characters, but
encodeURI/encodeURIComponent and its decode counterpartners are defined
since ECMAScript v3 (IE Windows 5.5 and N6 IE Mac ?).

 

[VK]

escape was introduced probably only for US-ASCII characters).

escape() and unescape() have been introduced for Common Gateway
Protocol (CGI) to encode / decode ASCII characters which are not
directly allowed for CGI transmission. These are all extended ASCII
chars (>127) and many symbols from the lower part of the ASCII table.

These methods have no idea about double (triple,.. and counting)
character units which constitute Unicode. So they cannot handle
properly Unicode characters but still can be used (though not
recommended) to handle traditional national encoding systems.

encodeURI
or encodeURIComponent() works very well and producing %C5%82. It
happens everytime no matter what charset in Content-Type of HTTP
response was used.
(becouse every string in JavaScript is in Unicode format - even
forms["myForm"].elements["myFormField"].value string).

You've got it! From withing JavaScript everything is Unicode, no matter
what encoding is used. The only complication I can think of is
document.location parts (if say .search field contains some non-Base
ASCII string and you want to read it. I encurage you to experiment).

Then it is wise to write/serve pages in UTF-8 when we want to make play
with i18n. Then at server side treat request params and its values as
UTF-8 strings.

Again: you do not have to worry about it. Your own tack is to save your
document in Unicode format (not UTF-8 ! - otherwise you'll get double
encoding on the trasmission) or in ASCII format with all non-base ASCII
chars transformed into \uFFFF escape sequences. And then you serve it
with UTF-8 Content-Type

[ Content-Type *doesn't* define the actual encoding *on* the page.
Content-Type defines what encoding browser should expect from
the server so it could parse received chars properly. ]

 

[Michael Winter]

(4) I have heard about 'this' keyword troubles, [...]

Did you actually read the follow-ups I posted to your previous
threads? There are /no/ 'troubles'.

He's mentioning the recently discussed issue with broken
(non-canonical) "this" context behavior in inner object classes.

No, that's how the language works. Different behaviour might have been
preferred, but that doesn't constitute 'broken'.

[snip]

...an error in the ECMAScript Language Specification which
causes this to be set incorrectly for inner functions.
-- Douglas Crockford,
<http://www.crockford.com/javascript/private.html>

As much as I respect Douglas, I don't agree with that statement. The
caller is supposed to provide a value for the this operator, and that
situation is just fine. The main problem is that because IE only
relatively recently implemented the means to provide that value, it's
forced the current solution.

Mike

 

[Luke Matuszewski]

VK napisal(a):

Again: you do not have to worry about it. Your own tack is to save your
document in Unicode format (not UTF-8 ! - otherwise you'll get double
encoding on the trasmission) or in ASCII format with all non-base ASCII
chars transformed into \uFFFF escape sequences. And then you serve it
with UTF-8 Content-Type

What i mean is to write page and save it using UTF-8 (so Unicode
characters gets transformed in a way the UTF-8 transformation format
wants it to be transformed) so:
- characters from US-ASCII take one byte in UTF-8 encoding;
- characters from out of it takes one, two or more bytes in UTF-8
encoding
(while in UTF-16 one char - even form US-ASCII - takes 2 bytes in file
and there are some chars that takes 4 bytes).
When file is saved if can be transmitted by server - and server should
know what charset to assign in ContentType HTTP header, so then browser
will properly decode the document and identify characters (like html
elements).
http://www.w3.org/TR/REC-html40/charset.html#h-5.1
[ The document character set, however, does not suffice to allow user
agents to correctly interpret HTML documents as they are typically
exchanged -- encoded as a sequence of bytes in a file or during a
network transmission. User agents must also know the specific character
encoding that was used to transform the document character stream into
a byte stream. ]
http://www.w3.org/TR/REC-html40/charset.html#h-5.2
[ The "charset" parameter identifies a character encoding, which is a
method of converting a sequence of bytes into a sequence of characters.
This conversion fits naturally with the scheme of Web activity: servers
send HTML documents to user agents as a stream of bytes; user agents
interpret them as a sequence of characters. The conversion method can
range from simple one-to-one correspondence to complex switching
schemes or algorithms. ]
http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2
[ How does a server determine which character encoding applies for a
document it serves? Some servers examine the first few bytes of the
document, or check against a database of known files and encodings.
Many modern servers give Web masters more control over charset
configuration than old servers do. Web masters should use these
mechanisms to send out a "charset" parameter whenever possible, but
should take care not to identify a document with the wrong "charset"
parameter value.
] and [
How does a user agent know which character encoding has been used? The
server should provide this information. The most straightforward way
for a server to inform the user agent about the character encoding of
the document is to use the "charset" parameter of the "Content-Type"
header field of the HTTP protocol ([RFC2616], sections 3.4 and 14.17)
For example, the following HTTP header announces that the character
encoding is EUC-JP:

Content-Type: text/html; charset=EUC-JP
]
http://www.w3.org/TR/REC-html40/conform.html#h-4.3
[ The optional parameter "charset" refers to the character encoding
used to represent the HTML document as a sequence of bytes. Legal
values for this parameter are defined in the section on character
encodings. Although this parameter is optional, we recommend that it
always be present. ]

The transformation of document which lies on some server and is
actually served depends on configuration of server (as read above) - so
if i use UTF-8 to save files and 'set' server to serve document with
charset=UTF-8 no further transformation of document which is file on
server should take place.

 

[Michael Winter]

On 22/11/2005 15:00, Luke Matuszewski wrote:

[snip]

(2.2) Should i use XmlHttpRequest object [...] or i must consider
using something like jsrs:

[snip]

I would like to have a page with few <select> elements in form. When
one select changes its selected value i would like to make a request to
the server CGI [...]

Presumably to get data with which you can change the other SELECT
elements? Yes, using XMLHttpRequest is fine for that. However, later in
your code you seem to be using the XML response data. I would have
thought it easier to return data formatted using JSON. An array of
objects containing the text/value pairs for the OPTION elements:

[ { text : 'Option 1', value : '1' },
{ text : 'Option 2', value : '2' },
...
{ text : 'Option n', value : 'n' } ]

You could simply loop through each element.

If I presumed wrong, XML might be the better format.

[snip]

function getMyXmlHttpRequestObject() {
var x = null;
try {
x=new ActiveXObject("Msxml2.XMLHTTP")
} catch(e) {
try {
x=new ActiveXObject("Microsoft.XMLHTTP")
} catch(sc) {
x=null
}
}
if( !x && typeof XMLHttpRequest != "undefined") {
x=new XMLHttpRequest()
}
return x;
}

I'd go with something more along the lines of:

function getRequestObject() {
var request = null;

if( ('function' == typeof XMLHttpRequest)
|| ('object' == typeof XMLHttpRequest))
{
request = new XMLHttpRequest();
} else if('function' == typeof ActiveXObject) {
/*@cc_on @*/
/*@if(@_jscript_version >= 5)
try {
request = new ActiveXObject('Msxml2.XMLHTTP');
} catch(e) {
try {
request = new ActiveXObject('Microsoft.XMLHTTP');
} catch(e) {
request = null;
}
}
@end @*/
}
return request;
}

[snip]

x.onreadystatechange = changeOptionsInAllSelect(
selectElem.form,
x);

You do realise that you're assigning the /result/ of calling that
function to the onreadystatechange property, not assigning the function
itself with some arguments, right?

1. (if the above script is on the page which was served in Content-Type
as text/html and with charset UTF-8, furthermore the <meta> element
with Content-Type suggest that charset is UTF-8)

You shouldn't be using META elements to indicate either MIME type or
encoding. That's what the HTTP Content-Type header is for.

The encoding of request parameter send (value of selected element) is
UTF-8.

As far as I'm aware, some implementations force UTF-8, irrespective of
the character encoding used by the document. Microsoft's (rather patchy)
documentation certainly seems to indicate this.

[snip]

Mike

 

[VK]

I may keep your document in UTF-8 format and you may ask your server
admin to turn off encoding mechanics so such document would not be
double encoded while sending. But why would you want to do this? And
it's definitely would not improve your text portability because you
would have to make the same agreement with each server admin. HTTP
protocol just doesn't work this way and I have great doubts that you
will manage to change HTTP standards on all servers across the globe


Effectively your idea is similar to keep all executables on your
computer in base64 text format and turn off your browser's base64
encoder so you could upload your file onto server manually. It is also
doable but in the Name why? ;-)

Coming back to the JavaScript internationalization portability: the
really secure way is to keep your code in Base ASCII format with all
non-Base ASCII characters represented in \uFFFF Unicode escape
sequences. This way there is no way that the encoding will be anyhow
corrupted.
As a development with \u all around is not convenient, you may want to
develope your JavaScript application in your national encoding and use
some converter (escaper ?) on the final phase.

Hope this help.