Another AJAX question

[sheldonlg]

I am looking for a clean solution to a problem that I solved in, what I
call, a "dirty" way.

Here is what I want to do. I have a dropdown list. Clicking on an item
in the dropdown list invokes an AJAX call that gets data which populates
the entire lower part of my screen. It does this with an innerHTML for
the div tag that holds all of this. This works fine.

I also have an "Edit" button that I want to show next to dropdown list,
but only if certain conditions are met for the item selected. I don't
know those conditions until after the AJAX call (which has the db query).

The way I tried to implement this was to create a hidden field in the
area written from the AJAX call, with its value set to 0 or 1 during the
AJAX call. On return, right after doing the innerHTML, in the same
javascript function, I interrogate that hidden field and set the display
attribute of the span encompassing the "Edit" button to either '' or none.

In the initial composition of the page, I selected the first item in the
dropdown list and called the inside code to generate the stuff inside
the div so that my page is initially filled.

Here is the problem. I have two items in the dropdown list. The first
one generates a 0 for the hidden field. The second generates a 1. (I
have put print statements into the code and those values are calculated
properly.) However, the edit button never shows. So, when the second
one is being displayed (where it should be 1 and show the edit button),
I did a view source. What appeared was the entire display for the first
one along with a value of 0.

So, here is my question. How can I transfer information within the AJAX
call, other that the entire bottom display which works fine, so that I
can do the post-processing to either hide or show the edit button.

I thought it might be an "imprinting" of this hidden variable, but it is
not. I moved that piece of code out of the inital page build and only
appearing in the AJAX call. Of course, the hidden variable didn't show
up at all since the view source only showed the results for the first
one which did not use the AJAX call.

I implemented a rather "dirty" way and it worked. I prepend the entire
return from AJAX with either a 0 or a 1. On the return, I separate the
two, and then innerHTML with the string start at position 1 and use the
first value for show/hide. However, I was wondering if there is a
better, cleaner, way.

[GArlington]

On Jun 5, 1:36 pm, sheldonlg <sheldonlgwrote:

I am looking for a clean solution to a problem that I solved in, what I
call, a "dirty" way.

Here is what I want to do. I have a dropdown list. Clicking on an item
in the dropdown list invokes an AJAX call that gets data which populates
the entire lower part of my screen. It does this with an innerHTML for
the div tag that holds all of this. This works fine.

I also have an "Edit" button that I want to show next to dropdown list,
but only if certain conditions are met for the item selected. I don't
know those conditions until after the AJAX call (which has the db query).

The way I tried to implement this was to create a hidden field in the
area written from the AJAX call, with its value set to 0 or 1 during the
AJAX call. On return, right after doing the innerHTML, in the same
javascript function, I interrogate that hidden field and set the display
attribute of the span encompassing the "Edit" button to either '' or none.

In the initial composition of the page, I selected the first item in the
dropdown list and called the inside code to generate the stuff inside
the div so that my page is initially filled.

Here is the problem. I have two items in the dropdown list. The first
one generates a 0 for the hidden field. The second generates a 1. (I
have put print statements into the code and those values are calculated
properly.) However, the edit button never shows. So, when the second
one is being displayed (where it should be 1 and show the edit button),
I did a view source. What appeared was the entire display for the first
one along with a value of 0.

So, here is my question. How can I transfer information within the AJAX
call, other that the entire bottom display which works fine, so that I
can do the post-processing to either hide or show the edit button.

I thought it might be an "imprinting" of this hidden variable, but it is
not. I moved that piece of code out of the inital page build and only
appearing in the AJAX call. Of course, the hidden variable didn't show
up at all since the view source only showed the results for the first
one which did not use the AJAX call.

I implemented a rather "dirty" way and it worked. I prepend the entire
return from AJAX with either a 0 or a 1. On the return, I separate the
two, and then innerHTML with the string start at position 1 and use the
first value for show/hide. However, I was wondering if there is a
better, cleaner, way.

Try
if (yourConditionIsMet){
thisElement.style.display = "block";
thisElement.style.visibility = "visible";
}
else {
thisElement.style.display = "none";
thisElement.style.visibility = "hidden";
}

[Dan Rumney]

sheldonlg wrote:

I am looking for a clean solution to a problem that I solved in, what I
call, a "dirty" way.

[snip]

Could you provide your dirty code, please?

[VK]

On Jun 5, 4:36 pm, sheldonlg <sheldonlgwrote:

So, here is my question. How can I transfer information within the AJAX
call, other that the entire bottom display which works fine, so that I
can do the post-processing to either hide or show the edit button.

I would go with the response headers. On practice I am regularly using
"Allow" header for similar purposes. The benefits are that this header
is explicitly forbidden for modifications by proxy servers and useful
to store proprietary info. In the case of a simple yes/no flag it is
enough to send a regular set for the content allowed to be edited:
Allow: HEAD, GET, POST
In this case the presence itself of such header would mean "yes":
if !!(myXHR.getResponseHeader('Allow')) {
// show "Edit" button
}
Maybe an explicit keyword would be still more clean and secure:
Allow: HEAD, GET, POST, EDITING
and then:
if (myXHR.getResponseHeader('Allow').lastIndexOf('EDI TING') != -1) {
// show "Edit" button
}

It would be a trivia to modify your server-side script to send
additional "Allow" response header for editable content.

[sheldonlg]

VK wrote:

On Jun 5, 4:36 pm, sheldonlg <sheldonlgwrote:

>So, here is my question. How can I transfer information within the AJAX
call, other that the entire bottom display which works fine, so that I
can do the post-processing to either hide or show the edit button.

I would go with the response headers. On practice I am regularly using
"Allow" header for similar purposes. The benefits are that this header
is explicitly forbidden for modifications by proxy servers and useful
to store proprietary info. In the case of a simple yes/no flag it is
enough to send a regular set for the content allowed to be edited:
Allow: HEAD, GET, POST
In this case the presence itself of such header would mean "yes":
if !!(myXHR.getResponseHeader('Allow')) {
// show "Edit" button
}
Maybe an explicit keyword would be still more clean and secure:
Allow: HEAD, GET, POST, EDITING
and then:
if (myXHR.getResponseHeader('Allow').lastIndexOf('EDI TING') != -1) {
// show "Edit" button
}

It would be a trivia to modify your server-side script to send
additional "Allow" response header for editable content.

This sounds like what I was looking for.

I haven't done this before so I have a few (probably elementary)
questions. I assume that I would have to add that header at the server
side of the call. In php, I guess that would be with a "header"
statement. What, then, do I print? I would assume that it is a string
with the header statement and the content appended afterwards. On the
JS side, does the responseText ignore the header? I would assume so.

[slebetman]

On Jun 5, 9:36 pm, sheldonlg <sheldonlgwrote:

Dan Rumney wrote:

sheldonlg wrote:

I am looking for a clean solution to a problem that I solved in, what
I call, a "dirty" way.

[snip]

Could you provide your dirty code, please?

Sure (in a mixture of code and pseudocode):

****************

Javascript processing:
(...the important two lines in handling the response...)
var resp = postProcess(pObjRequest.responseText);
document.getElementById('foo').innerHTML = resp;

function postProcess(txt) {
var hideIt = txt.substring(0,1);
var editButton = document.getElementById('showEdit');
if (hideIt == 0)
editButton.style.display = 'none';
else
editButton.style.display = '';
return txt.substring(1);

}

You can of course use closure to pass the required parameter:

var hideIt; // the variable you wish to pass
ajax.onreadystatechange = function () {
if (ajax.readyState == 4) {
if (hideIt) {// here you can use the variable..}
}
}

If you want to pass the value rather than the variable itself:

var hideIt;
(function (myHideIt) {
ajax.onreadystatechange = function () {
if (ajax.readyState == 4) {
if (myHideIt) {// check the passed value..}
}
}
})(hideIt) // pass the value of hideIt

Or if you prefer, you can wrap this up in a function that generates a
function:

function makeAjaxCallback (ajaxObject,myHideIt) {
return function () {
if (ajaxObject.readyState == 4) {
if (myHideIt) {// check the passed value..}
}
}
}
ajax.onreadystatechange = makeAjaxCallback(ajax,hideIt);

There are many ways to use closure to do this depending on exactly
what you want and, to some degree, preferred style.

[sheldonlg]

slebetman wrote:

On Jun 5, 9:36 pm, sheldonlg <sheldonlgwrote:

>Dan Rumney wrote:

>>sheldonlg wrote:
I am looking for a clean solution to a problem that I solved in, what
I call, a "dirty" way.
[snip]
Could you provide your dirty code, please?

Sure (in a mixture of code and pseudocode):

****************

Javascript processing:
(...the important two lines in handling the response...)
var resp = postProcess(pObjRequest.responseText);
document.getElementById('foo').innerHTML = resp;

function postProcess(txt) {
var hideIt = txt.substring(0,1);
var editButton = document.getElementById('showEdit');
if (hideIt == 0)
editButton.style.display = 'none';
else
editButton.style.display = '';
return txt.substring(1);

}

You can of course use closure to pass the required parameter:

var hideIt; // the variable you wish to pass
ajax.onreadystatechange = function () {
if (ajax.readyState == 4) {
if (hideIt) {// here you can use the variable..}
}
}

If you want to pass the value rather than the variable itself:

var hideIt;
(function (myHideIt) {
ajax.onreadystatechange = function () {
if (ajax.readyState == 4) {
if (myHideIt) {// check the passed value..}
}
}
})(hideIt) // pass the value of hideIt

Or if you prefer, you can wrap this up in a function that generates a
function:

function makeAjaxCallback (ajaxObject,myHideIt) {
return function () {
if (ajaxObject.readyState == 4) {
if (myHideIt) {// check the passed value..}
}
}
}
ajax.onreadystatechange = makeAjaxCallback(ajax,hideIt);

There are many ways to use closure to do this depending on exactly
what you want and, to some degree, preferred style.

I don't understand. How is the hideIt variable set (in the php
script)?. How does the javascript know that there is a variable hideIt
that is coming back? My line:

var resp = postProcess(pObjRequest.responseText);

is already inside an

if (ajaxObject.readyState == 4) {}

block that returns the string for the innerHTML.

[beegee]

On Jun 6, 7:47*am, sheldonlg <sheldonlgwrote:

slebetman wrote:

I don't understand. *How is the hideIt variable set (in the php
script)?. *How does the javascript know that there is a variable hideIt
that is coming back? *My line:

var resp = postProcess(pObjRequest.responseText);

is already inside an

if (ajaxObject.readyState == 4) {}

block that returns the string for the innerHTML.

Okay. Asynchronous Javascript XML = AJAX. HTML is not a transport
protocol and generating HTML on the server through PHP responses sort
of contradicts the purpose of AJAX. Rethink your design. Use
Javascript to generate markup from data, use XML or JSON for
transporting that data. If you do this, some of the other poster's
solutions will begin to make sense.

I know there are tons of examples on the net of AJAH but, in my humble
opinion, that's why they're called script kiddies.

Bob

[sheldonlg]

beegee wrote:

On Jun 6, 7:47 am, sheldonlg <sheldonlgwrote:

>slebetman wrote:

>I don't understand. How is the hideIt variable set (in the php
script)?. How does the javascript know that there is a variable hideIt
that is coming back? My line:

var resp = postProcess(pObjRequest.responseText);

is already inside an

if (ajaxObject.readyState == 4) {}

block that returns the string for the innerHTML.

Okay. Asynchronous Javascript XML = AJAX. HTML is not a transport
protocol and generating HTML on the server through PHP responses sort
of contradicts the purpose of AJAX. Rethink your design. Use
Javascript to generate markup from data, use XML or JSON for
transporting that data. If you do this, some of the other poster's
solutions will begin to make sense.

I know there are tons of examples on the net of AJAH but, in my humble
opinion, that's why they're called script kiddies.

Bob

I **think** I understand what you are saying.

This application happens to be for recipes, and the dropdown list is a
list of recipes. That dropdown list is not created through AJAX. Now,
when the user clicks on a particular recipe, I send an AJAX call. On
the server it looks up the data for the recipe from the database. What
I then do now is to generate the entire html portion of the recipe to
fit into a div on the bottom of the page (via innerHTML).

I guess what you are saying is to send back an xml string containing the
data and use javacript on the browser to process that xml string,
placing all the data into the appropriate tags on the bottom of the page
(since the bottom of the page always has the same fields). In that
case, including another field in the XML would, indeed, be trivial.

Am I reading you correctly?

[beegee]

On Jun 6, 10:21 am, sheldonlg <sheldonlgwrote:

beegee wrote:

On Jun 6, 7:47 am, sheldonlg <sheldonlgwrote:

slebetman wrote:

I don't understand. How is the hideIt variable set (in the php
script)?. How does the javascript know that there is a variable hideIt
that is coming back? My line:

var resp = postProcess(pObjRequest.responseText);

is already inside an

if (ajaxObject.readyState == 4) {}

block that returns the string for the innerHTML.

Okay. Asynchronous Javascript XML = AJAX. HTML is not a transport
protocol and generating HTML on the server through PHP responses sort
of contradicts the purpose of AJAX. Rethink your design. Use
Javascript to generate markup from data, use XML or JSON for
transporting that data. If you do this, some of the other poster's
solutions will begin to make sense.

I know there are tons of examples on the net of AJAH but, in my humble
opinion, that's why they're called script kiddies.

Bob

I **think** I understand what you are saying.

This application happens to be for recipes, and the dropdown list is a
list of recipes. That dropdown list is not created through AJAX. Now,
when the user clicks on a particular recipe, I send an AJAX call. On
the server it looks up the data for the recipe from the database. What
I then do now is to generate the entire html portion of the recipe to
fit into a div on the bottom of the page (via innerHTML).

I guess what you are saying is to send back an xml string containing the
data and use javacript on the browser to process that xml string,
placing all the data into the appropriate tags on the bottom of the page
(since the bottom of the page always has the same fields). In that
case, including another field in the XML would, indeed, be trivial.

Am I reading you correctly?

Yup. You have it. In this way you're emulating the classic client-
server application and keeping UI and data separate. If you don't
care about security too much, JSON is a even better bet than XML cause
there is no parsing involved on the Javascript side. You just eval
the result and you've got a javascript object.

Bob

[Jorge]

On Jun 5, 3:36*pm, sheldonlg <sheldonlgwrote:

>
Javascript processing:
(...the important two lines in handling the response...)
var resp = postProcess(pObjRequest.responseText);
document.getElementById('foo').innerHTML = resp;

function postProcess(txt) {
* *var hideIt = txt.substring(0,1);
* *var editButton = document.getElementById('showEdit');
* *if (hideIt == 0)
* * *editButton.style.display = 'none';
* *else
* * *editButton.style.display = '';
* *return txt.substring(1);

}

What's wrong with that ?
I'd say that that's perfect.
Why don't you like it this way ?

But just for the sake of changing something :

function postProcess(txt) {
var s= document.getElementById('showEdit').style;
s.display = (txt.substring(0,1) === "0") ? 'none' : '';
return txt.substring(1);
}

--Jorge.

[sheldonlg]

Jorge wrote:

On Jun 5, 3:36 pm, sheldonlg <sheldonlgwrote:

>Javascript processing:
(...the important two lines in handling the response...)
var resp = postProcess(pObjRequest.responseText);
document.getElementById('foo').innerHTML = resp;

function postProcess(txt) {
var hideIt = txt.substring(0,1);
var editButton = document.getElementById('showEdit');
if (hideIt == 0)
editButton.style.display = 'none';
else
editButton.style.display = '';
return txt.substring(1);

}

What's wrong with that ?
I'd say that that's perfect.
Why don't you like it this way ?

I get an uncomfortable feeling when I do a quick-and-dirty like this,
just to get it tow work. I like the cleaner approach that was told to
me in another response in this thread. There, on the server, I would
prepare an XML statement to pass back all the data for the bottom of the
page. I would also add in a field, <showEditwith the value of 0 or 1
inserted for the data. At the browser I would then process the XML to
get ALL the data, including this field, and do what was necessary for
all the fields.

I say "would", because I had already done what I showed up above. It
works and I am a firm believer in "if it ain't broke, don't fix it".
next time, though ....

[Jorge]

On Jun 7, 8:31*pm, sheldonlg <sheldonlgwrote:

What's wrong with that ?
I'd say that that's perfect.
Why don't you like it this way ?

I get an uncomfortable feeling when I do a quick-and-dirty like this,
just to get it tow work. *I like the cleaner approach that was told to
me in another response in this thread. *There, on the server, I would
prepare an XML statement to pass back all the data for the bottom of the
page. *I would also add in a field, <showEditwith the value of 0 or 1
inserted for the data. *At the browser I would then process the XML to
get ALL the data, including this field, and do what was necessary for
all the fields.

Rewrite it all, server and client-side, and send it as an XML doc just
because you need a boolean to enable/disable a single button ?
Hmm, you must be kidding, that's not a good idea, imho.

--Jorge.

[sheldonlg]

Jorge wrote:

On Jun 7, 8:31 pm, sheldonlg <sheldonlgwrote:

>>What's wrong with that ?
I'd say that that's perfect.
Why don't you like it this way ?

I get an uncomfortable feeling when I do a quick-and-dirty like this,
just to get it tow work. I like the cleaner approach that was told to
me in another response in this thread. There, on the server, I would
prepare an XML statement to pass back all the data for the bottom of the
page. I would also add in a field, <showEditwith the value of 0 or 1
inserted for the data. At the browser I would then process the XML to
get ALL the data, including this field, and do what was necessary for
all the fields.

Rewrite it all, server and client-side, and send it as an XML doc just
because you need a boolean to enable/disable a single button ?
Hmm, you must be kidding, that's not a good idea, imho.

--Jorge.

No, no. I am not rewriting anything. All I am saying is that a better
techniques is to separate the data from the presentation. That is why
to send the data via xml and let the client side handle the
presentation. That is even without the boolean. Adding the boolean is
simple if I had done it that way. The current code works and I am not
rewriting it. However, next time I will do it the XML way because that
leads to easier modifications and enhancements and does not require yet
another addition of yet another hack if something else comes along that
is required.

[Dr J R Stockton]

In comp.lang.javascript message <b85ae10a-47d8-4e09-ab31-20c99ef24794@8g
2000hse.googlegroups.com>, Sat, 7 Jun 2008 08:46:54, Jorge
<jo***@jorgechamorro.composted:

>But just for the sake of changing something :

function postProcess(txt) {
var s= document.getElementById('showEdit').style;
s.display = (txt.substring(0,1) === "0") ? 'none' : '';
return txt.substring(1);
}

Or
s.display = (txt.charAt(0) === "0") ? 'none' : ''; // untested

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)

[Jorge]

On Jun 8, 6:19*pm, Dr J R Stockton <[e-mail]:

>
Or
* * s.display = (txt.charAt(0) === "0") ? 'none' : ''; *// untested

Or

s.display = (txt[0] === "0") ? 'none' : '';
// tested in Safari, FF and Opera.

/8¬)

--Jorge.

[Thomas 'PointedEars' Lahn]

Jorge wrote:

On Jun 8, 6:19 pm, Dr J R Stockton <[e-mail]:

>Or
s.display = (txt.charAt(0) === "0") ? 'none' : ''; // untested

Or

s.display = (txt[0] === "0") ? 'none' : '';
// tested in Safari, FF and Opera.

The possibility of accessing string values as if they were an array of
characters is a proprietary extension of ECMAScript that should not be
relied on. It does not work in IE/MSHTML, for example, which makes it
rather not viable on the Web. (I should add that feature to the ES Matrix.)

However, when necessary it is easy to make an array of characters out of a
string: txt.split("").
F'up2 cljs

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Jorge]

On Jun 8, 11:37*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

(...) txt[0] === "0" (...)

(...) does not work in IE/MSHTML, for example, (...)

"for example" ?

ROTFLOL... how come... IE *again*, one more time ?

Math.pow(LOL, 16384);

--Jorge.

[Thomas 'PointedEars' Lahn]

Jorge wrote:

Thomas 'PointedEars' Lahn wrote:

>>(...) txt[0] === "0" (...)

(...) does not work in IE/MSHTML, for example, (...)

"for example" ?

Since this is a proprietary extension to the ECMAScript Language
Specification, it is possible that there is more than one implementation of
it that does not provide the feature.

ROTFLOL... how come... IE *again*, one more time ?

Microsoft JScript does not provide this language feature.

Math.pow(LOL, 16384);

Didn't you mean to say

Math.pow(LOL, Math.pow(2, 14));

? I also wonder about the value of LOL.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Dr J R Stockton]

In comp.lang.javascript message <1cc2d6f2-33dc-4e5b-9633-9bec28efc120@l4
2g2000hsc.googlegroups.com>, Sun, 8 Jun 2008 13:21:56, Jorge
<jo***@jorgechamorro.composted:

>
s.display = (txt[0] === "0") ? 'none' : '';
// tested in Safari, FF and Opera.

Only when writing for a rigorously-controlled intranet can it be safe to
omit testing in MS IE.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk BP7, Delphi 3 & 2006.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htmclpdmFAQ;
Via <URL:http://support.codegear.com/newsgroups/>: news:borland.* Guidelines

[Michael Wojcik]

[Followups restricted to c.l.j.]

Dr J R Stockton wrote:

In comp.lang.javascript message <1cc2d6f2-33dc-4e5b-9633-9bec28efc120@l4
2g2000hsc.googlegroups.com>, Sun, 8 Jun 2008 13:21:56, Jorge
<jo***@jorgechamorro.composted:

>s.display = (txt[0] === "0") ? 'none' : '';
// tested in Safari, FF and Opera.

Only when writing for a rigorously-controlled intranet can it be safe to
omit testing in MS IE.

What about Greasemonkey scripts? What about Yahoo Widgets? What about
ECMAScript programs, in short, that are written specifically to run
under a particular implementation?

That implementation may even be a browser, for that matter; I've
written ECMAScript applications that are only supported under the
Mozilla engine. You want to run them, you run them under a Mozilla
derivative. There's no compelling need for me to make them run under
other implementations, any more than I have a need to stick to ISO C
for all of my C applications.

I'd agree that when writing scripts for general use, testing under
Microsoft's implementation is advisable, but "a rigorously-controlled
intranet" is hardly the only alternative to "general use".

Sometimes the c.l.j regulars - excellent though much of their advice
may be - appear to forget that there are uses for ECMAScript other
than scripting general-use web pages.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[Thomas 'PointedEars' Lahn]

Michael Wojcik wrote:

Dr J R Stockton wrote:

>In comp.lang.javascript message
<1cc2d6f2-33dc-4e5b-9633-9bec28efc120@l4 2g2000hsc.googlegroups.com>,
Sun, 8 Jun 2008 13:21:56, Jorge <jo***@jorgechamorro.composted:

>>s.display = (txt[0] === "0") ? 'none' : ''; // tested in Safari, FF
and Opera.

Only when writing for a rigorously-controlled intranet can it be safe
to omit testing in MS IE.

What about Greasemonkey scripts? What about Yahoo Widgets? What about
ECMAScript programs, in short, that are written specifically to run under
a particular implementation?

ACK for Greasemonkey scripts. But are Yahoo widgets really written
specifically to run under a particular implementation?

That implementation may even be a browser,

A Web browser is not an ECMAScript implementation; it may provide one.

for that matter; I've written ECMAScript applications that are only
supported under the Mozilla engine. You want to run them, you run them
under a Mozilla derivative.

More specifically, you are required to have XUL support before being able to
run them. At least that is the only justification for this restriction that
I could accept.

There's no compelling need for me to make them run under other
implementations, any more than I have a need to stick to ISO C for all of
my C applications.

True, but this thread was about something else.

I'd agree that when writing scripts for general use, testing under
Microsoft's implementation is advisable, but "a rigorously-controlled
intranet" is hardly the only alternative to "general use".

True, because even an intranet that is seemingly "rigorously controlled" now
does not need to be so later. IMHO, the competent developer would attempt
to cover as many possibilities of access as possible; that is, they do not
exclude any in the first place, especially not when it is probable to occur.

Sometimes the c.l.j regulars - excellent though much of their advice may
be - appear to forget that there are uses for ECMAScript other than
scripting general-use web pages.

Sometimes it is necessary to point out that a suggested feature is not
universally available. AFAICS, this thread was about "AJAX" in HTML user
agents in general and so the remarks regarding differences in
implementations were justified.
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>

[Michael Wojcik]

Thomas 'PointedEars' Lahn wrote:

Michael Wojcik wrote:

>Dr J R Stockton wrote:

>>In comp.lang.javascript message
<1cc2d6f2-33dc-4e5b-9633-9bec28efc120@l4 2g2000hsc.googlegroups.com>,
Sun, 8 Jun 2008 13:21:56, Jorge <jo***@jorgechamorro.composted:
s.display = (txt[0] === "0") ? 'none' : ''; // tested in Safari, FF
and Opera.
Only when writing for a rigorously-controlled intranet can it be safe
to omit testing in MS IE.

What about Greasemonkey scripts? What about Yahoo Widgets? What about
ECMAScript programs, in short, that are written specifically to run under
a particular implementation?

ACK for Greasemonkey scripts. But are Yahoo widgets really written
specifically to run under a particular implementation?

Yes - they run under Konfabulator. Are we talking about the same thing?

>That implementation may even be a browser,

A Web browser is not an ECMAScript implementation; it may provide one.

Right. Sloppy phrasing on my part.

>for that matter; I've written ECMAScript applications that are only
supported under the Mozilla engine. You want to run them, you run them
under a Mozilla derivative.

More specifically, you are required to have XUL support before being able to
run them. At least that is the only justification for this restriction that
I could accept.

You're not required to accept my justification - which is that if I'm
writing an application to solve some problem of interest to me, I may
or may not be interested in making it cross-implementation compatible.

I have been working on an application for my own purposes which
happens to be written in ECMAScript. Some people have expressed
interest in it, and that's fine, but they'll have to run it in the
same implementation I use, or they'll have to port it themselves.
Making it run everywhere is not one of my goals.

>There's no compelling need for me to make them run under other
implementations, any more than I have a need to stick to ISO C for all of
my C applications.

True, but this thread was about something else.

This subthread - starting with my reply to the good doctor - is about
when it is advisable to test ECMAScript programs under IE.

Sometimes it is necessary to point out that a suggested feature is not
universally available. AFAICS, this thread was about "AJAX" in HTML user
agents in general and so the remarks regarding differences in
implementations were justified.

Such remarks are nearly always justified, in my opinion. When those
remarks include absolutes like the "Only when..." above, however, they
need to be qualified. You can certainly argue (as you did) that a
suitable qualification was implicit in the context; I thought it
better to make one explicit.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University