prototype.js object persistance

[bigdadro]

I've created a new class using prototype.js. After I make the
ajax.request all references to this.myClassMethodorVariable are lost.
Does the ajax method blow out the object persistance? I'm fairly new to
OOP javascript so could be (and probably am) overlooking some detail.
Below is the logic of what i'm trying to do.

//Javascript code
var myClass = Class.create();
myClass.prototype={
initialize: function(fm) {
//Static Variables
this.myMessage = 'hello';
this.myName = 'Nick';
this.frm = fm;
this.WSURL = '/some/Server/script';
this.frm.onSubmit =
this.submitForm.bindAsEventListener(this);
},
submitForm: function(evt) {
var pars = myMessage;
var myAjax = new Ajax.Request( this.WSURL, { method: 'get',
parameters: pars, onSuccess: this.myHandler});
},
myHandler: function(ajaxResponse) {
this.myMessage(ajaxResponse.responseText);
},
myMessage: function(str) {
alert(str);
}
};

//HTML Code
<form name="someForm" id="someForm" method="post" action="##">
<input type="text" id="myText" />
<input type="submit" name="submit" value="submit">
</form>
<script>var testClass = new myClass('someform');</script>

[Randy Webb]

bi******@gmail.com said the following on 5/25/2006 2:03 PM:

I've created a new class using prototype.js.
There above is 99.99999999% of your problem. Using a worthless piece of
junk script library.
After I make the ajax.request all references to this.myClassMethodorVariable
are lost.

Stop using prototype.js, you don't have an issue with it anymore.

Why do people come here asking for help with a specific library instead
of going to the inept programmer who wrote that library?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[o0JoeCool0o]

>>Why do people come here asking for help with a specific library instead
of going to the inept programmer who wrote that library?

wow that was a useful contribution to the programming community.

I know how about nobody develops any libraries and we all take 2 months
to accomplish what can be done in 2 days.

better yet, lets boycott javascript altogether, after all it was prolly
written by some inept programmer.

[o0JoeCool0o]

Dont get me wrong I still dont think this is the place to ask for help
with other libraries they should have there own group and if they dont
have one its pretty easy to make one. (thats what I did for
scriptaculous anyway)

But its not fair to call the programmers of thsoe libraries inept, its
usally the person using the control who is inept.

[Matt Kruse]

o0JoeCool0o wrote:

Dont get me wrong I still dont think this is the place to ask for help
with other libraries they should have there own group and if they dont
have one its pretty easy to make one.
Most people here would agree.

Creating a js library using questionable programming techniques, then
providing very little documentation and no tech support seems kind of
anti-social, IMO.
But its not fair to call the programmers of thsoe libraries inept, its
usally the person using the control who is inept.

I think inept is a bit much. Clearly, the author of prototype.js has
technical knowledge and skills far beyond most js coders.
I think 'misguided' may be a better term.
But then, different people would apply that label to almost anyone, myself
included ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Randy Webb]

o0JoeCool0o said the following on 5/25/2006 3:39 PM:

Why do people come here asking for help with a specific library instead

of going to the inept programmer who wrote that library?
wow that was a useful contribution to the programming community.

Programming community? This is Usenet. Its a discussion group, nothing
more and nothing less.
I know how about nobody develops any libraries and we all take 2 months
to accomplish what can be done in 2 days.
If you are that inept, have at it.
better yet, lets boycott javascript altogether, after all it was prolly
written by some inept programmer.

Probably so. But I bet they can spell probably.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

o0JoeCool0o said the following on 5/25/2006 3:48 PM:

Don't get me wrong, but, I think people who repeatedly don't quote what
they are replying to are beyond inept.

Dont get me wrong I still dont think this is the place to ask for help
with other libraries they should have there own group and if they dont
have one its pretty easy to make one. (thats what I did for
scriptaculous anyway)
That is part of what makes them inept.

inept - lacking sense or reason : FOOLISH

And anybody that creates code such as prototype.js with it's complexity
without supporting it or even documenting it is, guess what? Inept.
But its not fair to call the programmers of thsoe libraries inept, its
usally the person using the control who is inept.

That may be true also. But I doubt it. The same can be said for eval.
eval itself may or may not be evil, its just the person using it, right?
Well, anybody that understands the problems/drawbacks of eval enough to
know when to use doesn't use it. Same with prototype.js. If the
programmer understands enough to wade through that code to determine
what it does can write there own in less time and have the added benefit
of knowing exactly what it is doing.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

o0JoeCool0o wrote:

But its not fair to call the programmers of thsoe libraries inept, its
usally the person using the control who is inept.

In this case (Prototype) it is. For it has been shown here that its author
ignored existing language features in favor of a newly invented wheel that
does not run with carriages that are little older than that he rode on, and
there are many examples on how to do much better than that.
PointedEars

[Ian Collins]

Thomas 'PointedEars' Lahn wrote:

o0JoeCool0o wrote:

But its not fair to call the programmers of thsoe libraries inept, its
usally the person using the control who is inept.

In this case (Prototype) it is. For it has been shown here that its author
ignored existing language features in favor of a newly invented wheel that
does not run with carriages that are little older than that he rode on, and
there are many examples on how to do much better than that.

Expect to see it more as the popularity of Ruby on Rails grows. This
framework is tied closely to Prototype.js.

There appears to be plenty of documentation at
http://www.sergiopereira.com/articles/prototype.js.html, might be a good
place to send people who ask here.

--
Ian Collins.

[petermichaux]

Randy Webb wrote:

The same can be said for eval.
eval itself may or may not be evil, its just the person using it, right?
Well, anybody that understands the problems/drawbacks of eval enough to
know when to use doesn't use it.

That last sentence seems to mean the the knowledgable don't ever use
eval. Doesn't JSON absolutely require the use of at least one eval? I
don't mean this to be nit picking. I'm curious if there is another way
to deal with a JSON response or if you think those using JSON should be
doing something else?

Peter

[petermichaux]

Ian Collins wrote:

Expect to see it more as the popularity of Ruby on Rails grows. This
framework is tied closely to Prototype.js.

I've been thinking about this too because I've been using Rails for
about 10 months and it seems like a solid framework. I like programming
with Rails and I have not encountered bugs. However the choice to use
Prototype.js as the core JavaScript library seems like it was a very
bad choice according to many here. Does this reflect on other choices
the Rails core team made or is this one of only a few poor choices?

Peter

[Randy Webb]

pe**********@gmail.com said the following on 5/26/2006 10:13 PM:

Randy Webb wrote:

The same can be said for eval.
eval itself may or may not be evil, its just the person using it, right?
Well, anybody that understands the problems/drawbacks of eval enough to
know when to use doesn't use it.
That last sentence seems to mean the the knowledgable don't ever use
eval.

That isn't what I meant. It means they don't use unless there is a
reason to use it. eval's purpose is to execute code unknown at runtime.
The problem with eval is people using it as a crutch such as:

eval('document.getElementById("someVar'+someOtherV ar+'").stlye.visibility');

instead of:

document.getElementById('someVar' + someOtherVar).style.visibility;

Or, the worst one lately was referencing global variables. Assume you
have 10 variables named myVar## and you want to get a reference to them
dynamically. How do you do it?

Well, you could do eval('myVar' + ##) but it's using a crutch when
window['myVar' + ##] does the same thing, does it quicker, and does it
without starting up the eval compiler.

And yes, I use it when it is needed. What is the best/quickest way to
convert a fraction to a decimal using JS? The answer depends on the
browser but some browsers do it quicker with eval than splitting the
fraction and dividing.
Doesn't JSON absolutely require the use of at least one eval?
Not sure, I very seldom use JSON.
I don't mean this to be nit picking.
And I didn't take it that way :)
I'm curious if there is another way to deal with a JSON response
or if you think those using JSON should be doing something else?

It depends on the JSON response. If all it is is data, you could create
a script element, insert the data, and off you go.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Ian Collins]

pe**********@gmail.com wrote:

Randy Webb wrote:

The same can be said for eval.
eval itself may or may not be evil, its just the person using it, right?
Well, anybody that understands the problems/drawbacks of eval enough to
know when to use doesn't use it.

That last sentence seems to mean the the knowledgable don't ever use
eval. Doesn't JSON absolutely require the use of at least one eval? I
don't mean this to be nit picking. I'm curious if there is another way
to deal with a JSON response or if you think those using JSON should be
doing something else?

I don't think there is another way, a JSON response is the textual
representation of an object which has to be converted into a live object.

--
Ian Collins.

[Lasse Reichstein Nielsen]

Ian Collins <ia******@hotmail.com> writes:

I don't think there is another way, a JSON response is the textual
representation of an object which has to be converted into a live object.

You could parse it directly. The grammar is simple enough.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Ian Collins]

Lasse Reichstein Nielsen wrote:

Ian Collins <ia******@hotmail.com> writes:

I don't think there is another way, a JSON response is the textual
representation of an object which has to be converted into a live object.

You could parse it directly. The grammar is simple enough.

True, but what advantage does that offer over eval?

--
Ian Collins.

[Lasse Reichstein Nielsen]

Ian Collins <ia******@hotmail.com> writes:

Lasse Reichstein Nielsen wrote:

Ian Collins <ia******@hotmail.com> writes:

I don't think there is another way, a JSON response is the textual
representation of an object which has to be converted into a live object.

You could parse it directly. The grammar is simple enough.

True, but what advantage does that offer over eval?

None, if you trust the sender. But it *is* another way than using eval.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

pe**********@gmail.com wrote:

Randy Webb wrote:

The same can be said for eval.
eval itself may or may not be evil, its just the person
using it, right? Well, anybody that understands the
problems/drawbacks of eval enough to know when to use
doesn't use it.
That last sentence seems to mean the the knowledgable don't
ever use eval.

99.9% of the uses of eval that you see are cases where the use of eval
is not necessary and the alternatives are objectively superior
(particularly, but not exclusively, regarding performance). The
knowledgeable javascript author does not use eval when is not
*necessary*. He/she also will tend to follow the axiom; if you think you
need to use eval the odds are very good that you are missing a much
better alternative. So when I say necessary I mean really thought about
and known to be absolutely the only way, or offering sufficient
advantages in context to compensate for its drawbacks and outweigh the
alternatives.
Doesn't JSON absolutely require the use of at least one eval?
Absolutely not. If JSON comes in through an XML HTTP request from a
trusted source (you own server side code) then eval probably is the
optimum mechanism for turning that into a javascript object structure.
JSON may come in in other ways, such as loaded into a hidden IFRAME
having been wrapped into a SCRIPT element on an HTML page, and JSON that
is passed on from a third party must never be evaled, rather actively
parsed by the client, else you are open to (potentially malicious)
script insertion along the lines of:-

{
prop:((function(){
/*

This is the body of a function expression that will be _called_ during
the eval-ing of the containing (apparent) JSON data and will do
something that you do not want to happen, such as change every link on
the current page to go to porn sites, or every input field to broadcast
whatever is entered to a third party, and so on.

*/
})())
}
I don't mean this to be nit picking. I'm curious if there is
another way to deal with a JSON response or if you think those
using JSON should be doing something else?

JSON is probably the most efficient data format for sending information
to client-side javascript, and eval is the most efficient (and widely
supported) way of turning a string of JSON data directly into object
with which javascript can interact. That does not mean that the people
using JSON do not have to put some thought into what they are doing.

Richard.

[Richard Cornford]

pe**********@gmail.com wrote:

Ian Collins wrote:

Expect to see it more as the popularity of Ruby on Rails
grows. This framework is tied closely to Prototype.js.
I've been thinking about this too because I've been using
Rails for about 10 months and it seems like a solid
framework. I like programming with Rails and I have not
encountered bugs.

How hard have you been trying to break it? We know that it will not
function with IE <= 5.5 (unless the JScript DLLs have been updated) and
that there are issues with current Opera versions. The odds are also
good that it will fall over if exposed to any less dynamic browser.

It is not difficult to write an IE only script and then never encounter
any issues with it, by the simple measure of never testing it with
anything but default installation of IE 6. (Which makes it particularly
embarrassing for Microsoft that MSDN repeatedly kicks out
'"parentElement.parentElement" is null or not an object' errors when
visited with a default instalation of IE 6 :)

(It is also interesting to note that Prototype.js's issues with JScript
< 5.6 mostly relate to the absence of Function.prototype.call and
Function.prototype.apply, both of which can be successfully emulated. So
a little feature detection and prototype augmentation can fix that
issue, where augmenting the prototype of Function is significantly less
problematic than augmenting the prototypes of Object or Array.)
However the choice to use Prototype.js as the core JavaScript
library seems like it was a very bad choice according to many
here.
Prototype.js appears to be client side code written by people with a
limited familiarity with javascript (such that, for example, the
contents of ECMA 262 where apparently unknown to them) and no real
appreciation of or love for the language anyway. There are attempts to
make javascript look and behave like another language, which obviously
will appeal to individuals familiar with that other language but is
almost certainly not going to be the best use of javascript.
Does this reflect on other choices the Rails core team made or
is this one of only a few poor choices?

It is not realistic to expect experts in one language to be in a
position to make good judgements about another. Part of the appeal of
client-side libraries is that one can be identified as apparently suited
to a task and the responsibility for the quality of the code it contains
abdicated to the author(s) of that library. Many people fall into that
(potential) trap in all innocence.

In any design for a combined server side-client side framework the
interface between the two should be as simple as possible, and probably
should be abstracted of the details of the languages on both sides. In
that case the choice of client side code does not matter much as it can
be regarded as provisional and better replacements found/created.

If server side and client side get too intertwined (as might be manifest
in, for example, the server sending actual javascript code (specific
function calls and the like, not merely data in JSON format) to be
evaled on the client) then the lack of flexibility in the entire system
is a poor design choice.

If Rails cannot work without Protoype.js then the issues with
Protyope.js will harm Rails. The vested interests my not want to see
that, but that doesn't mean it could not be true.

On the other hand, there is the question of what Rails is a framework
for. If it is for creating Internet applications with a restricted and
known UA base (so not for public commercial web use) then maybe the
issues with Prototype.js don't matter. The system is sufficient for its
role and being unsuited to other roles just means that it should not be
used in those contexts.

Richard.

[Dr John Stockton]

JRS: In article <4d*************@individual.net>, dated Sat, 27 May
2006 14:45:31 remote, seen in news:comp.lang.javascript, Ian Collins
<ia******@hotmail.com> posted :

I don't think there is another way, a JSON response is the textual
representation of an object which has to be converted into a live object.

Below, S is, I suppose, the textual representation of an object; it
appears that Ob ends up as a live object.

S = "{X:3}"
Fn = new Function("return "+S)
Ob = Fn()
alert(Ob.X)

And
function Obj(St) { return new Function("return "+St)() }

I'm not claiming any great advantage (though such may exist) other than
that of not exciting eval-hunters.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[sergioafp]

Well, people ranted and bashed but nobody cared to answer the question.
It seems that you're having trouble with the "this" keyword. Rule of
thumb: avoid "this" inside anonymous functions and also in functions
you pass around as references.
Change your submitForm method to:
submitForm: function(evt) {
var pars = myMessage;
var myAjax = new Ajax.Request( this.WSURL, { method: 'get',
parameters: pars, onSuccess: this.myHandler.bind(this)});
},

OR

submitForm: function(evt) {
var pars = myMessage;
var myObj = this;
var myAjax = new Ajax.Request( this.WSURL, { method: 'get',
parameters: pars, onSuccess: function(){ myObj.myHandler(arguments); }
} );
},

If I didn't goofed up something (not rare), one of the above options
should work for you.

I hope this helps.

- Sergio
http://www.sergiopereira.com/articles/

[Thomas 'PointedEars' Lahn]

se*******@gmail.com wrote:

Well, people ranted and bashed but nobody cared to answer the question.
Why should anyone care to further comment on or analyze code that uses a
codebase known to be junk? The error might as well lie in the codebase and
nobody that knows about its quality would be particularly inclined to dig
through it (without being paid for this QA task, perhaps). This is not a
help desk, you know.
[...] Rule of thumb: avoid "this" inside anonymous functions and also in
functions you pass around as references.

Utter nonsense.
PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Blanched Soldier"

[petermichaux]

Richard Cornford wrote:

pe**********@gmail.com wrote:

I've been using
Rails for about 10 months and it seems like a solid
framework. I like programming with Rails and I have not
encountered bugs.
How hard have you been trying to break it? We know that it will not
function with IE <= 5.5 (unless the JScript DLLs have been updated) and
that there are issues with current Opera versions. The odds are also
good that it will fall over if exposed to any less dynamic browser.

I meant I haven't encountered Rails bugs not Prototype.js bugs.
It is not realistic to expect experts in one language to be in a
position to make good judgements about another.
It takes a lot of time to learn HTML, CSS, JavaScript, Ruby, Rails and
all sorts of other technology like XML, JSON, SQL, Apache, Lighttpd,
UNIX, Rake, ftp, subversion,... So much to learn. Rails always
advertises that it makes programming fast and fun but only if you want
to program a regular Web 1.0 site with a few links and forms. Also the
say that you can use Ruby from top to bottom of their full stack but I
don't think that is very practical.

If server side and client side get too intertwined (as might be manifest
in, for example, the server sending actual javascript code

I think he Rails new rjs templates are a good idea and they do send
javascript to the client to update various portions of the web page. I
will have to spend some time removing the dependency on Prototype.js
for these rjs templates. That is one thing I don't like about them.

Peter

[Richard Cornford]

pe**********@gmail.com wrote:

Richard Cornford wrote:

pe**********@gmail.com wrote:

I've been using
Rails for about 10 months and it seems like a solid
framework. I like programming with Rails and I have not
encountered bugs.
How hard have you been trying to break it? ... <snip> I meant I haven't encountered Rails bugs not
Prototype.js bugs.
Too many negatives to parse.
It is not realistic to expect experts in one language to
be in a position to make good judgements about another.

It takes a lot of time to learn HTML, CSS, JavaScript, Ruby,
Rails and all sorts of other technology like XML, JSON, SQL,
Apache, Lighttpd, UNIX, Rake, ftp, subversion,... So much to
learn.

Precisely. It is not realistic to expect everyone to be an expert at
everything. So if an unfamiliar technology forms a critical (or even an
important) part of a system you find yourself someone with the pertinent
knowledge and experience to ask (or several people, if possible).
Rails always advertises that it makes programming fast
and fun but only if you want to program a regular Web
1.0 site with a few links and forms.
Like cabinet making with a chainsaw; fast and fun but the results ain't
Chippendale?

<snip>

If server side and client side get too intertwined (as
might be manifest in, for example, the server sending
actual javascript code

I think he Rails new rjs templates are a good idea

But you are not going to say what "rjs templates" are?
and they do send javascript to the client to update
various portions of the web page.
Better to send abstract instructions and parameters to the client (i.e.
pure data).
I will have to spend some time removing the dependency
on Prototype.js for these rjs templates. That is one
thing I don't like about them.

Swapping it for a dependence on other specific client-side code is not
necessarily a step forward.

Richard.

[petermichaux]

Richard Cornford wrote:

pe**********@gmail.com wrote:

Rails always advertises that it makes programming fast
and fun but only if you want to program a regular Web
1.0 site with a few links and forms.
Like cabinet making with a chainsaw; fast and fun but the results ain't
Chippendale?

I certainly didn't mean that. More specifically I meant Rails is fun
and fast for making Web 1.0 type pages. Rails is very good for Web 2.0
also. Rails is more like a cabinetmakers tablesaw with many jigs. You
still need a drillpress and sometimes even a milling machine. They are
working on drill press and millling machine jigs for Rails. That is
what I don't particularly like. If I need to have some client side
JavaScript I don't mind writing JavaScript. I suppose C coders heard
the same thing from Assembly coders.

<snip>

If server side and client side get too intertwined (as
might be manifest in, for example, the server sending
actual javascript code

I think he Rails new rjs templates are a good idea

But you are not going to say what "rjs templates" are?

It is a way to generate JavaScript using a Ruby template. It is
intended for inserting ajax responses into a current page where
multiple places in the page need updating. It is an exception to what I
said above. Here is the first thing I read about rjs templates.

http://scottraymond.net/articles/200...-rjs-templates

I imagine that after I prototype my application a little more I may run
into situations where rjs is more trouble than it is worth. Maybe not
though. They seem pretty good.

and they do send javascript to the client to update
various portions of the web page.

Better to send abstract instructions and parameters to the client (i.e.
pure data).

No matter which language you use to define the instructions sent to the
client, both the server and client must know this language. Why not use
JavaScript as this language? I don't see how there is a way to
completely untangle the server and client.

Peter

[Richard Cornford]

pe**********@gmail.com wrote:

Richard Cornford wrote:

pe**********@gmail.com wrote:

Rails always advertises that it makes programming fast
and fun but only if you want to program a regular Web
1.0 site with a few links and forms.
Like cabinet making with a chainsaw; fast and fun but the
results ain't Chippendale?

I certainly didn't mean that. More specifically I meant
Rails is fun and fast for making Web 1.0 type pages.
Rails is very good for Web 2.0 also.

That seems exactly as specific as the first time you expressed it.

You might care to consider what you are actually saying when you write
Web 1.0 and Web 2.0. Marketing-speak or something to which meaning could
be attached?

<snip>

If server side and client side get too intertwined (as
might be manifest in, for example, the server sending
actual javascript code

I think he Rails new rjs templates are a good idea

But you are not going to say what "rjs templates" are?

It is a way to generate JavaScript using a Ruby template.

Do you imagine that "Ruby template" means any more to me than "rjs
template"?
It is intended for inserting ajax responses into a current
page where multiple places in the page need updating.
Given the wide spectrum of ways in which that could be done that
description doesn't move this much further on than stating its name.
It is an exception to what I said above. Here is the first
thing I read about rjs templates.

http://scottraymond.net/articles/200...ls-rjs-templat
es

Web developers have quite a power to screw their clients over, whether
in ignorance, incompetence, idleness, disinterest in doing better or
malice. In this case I have to suspect one of the first two, given that
the page referenced above manages to show code examples (marked up as -
<code><pre> ... </pre><code> -, of all things) that overflow the
'sidebar', rendering both unreadable, and viewing the source reveals
Appendix C XHTML 1.0, being scripted in a way that _requires_ that the
document _never_ be interpreted as XHTML (an obvious contradiction that
would not be the product of an informed, rational mind).

The page itself tells the story of the automation of aspects of the
creation of a web site:-

<URL: http://www.iconbuffet.com/ >

- which can therefor be examined gauge the real worth of these "RJS
Templates".

It is interesting that the context in question is an "AJAX shopping
cart". Last week I had an opportunity to have a look at a copy of "AJAX
in Action" (mostly I wanted to find out why I am in the index, a novel
experience to date but not particularly significant in reality) and
ended up thinking some more about the appropriate application of AJAX.
The arguments for AJAX seem to stress its use in web applications, where
the user is going to be engaging in a long-ish term interaction with the
application in a browser. Where a smooth, responsive user interface will
assist them in their work.

It struck me that an e-commerce site was never a web application. The
purpose of e-commerce is primarily to take money off people, and the
user's interaction with such a site will be intermittent and hopefully
as short/easy as possible. Mostly with the intention of that interaction
ending in their making purchases.

Which is not to say that an e-commerce site should not have a smooth and
responsive UI, but that should not be achieved at the cost (literally)
of not being able to take money off some potential customers. At least I
don't think that a web developer has the right to employ techniques that
will cost a client turnover, profits and possibly future commercial
viability when there is no technical reason for doing that. (At the very
least, if such a technique is going to be used that decision should be
being made, on a fully informed bases, by whoever is responsible for
making business decisions not the web developers).

This makes AJAX shopping carts particularly significant as examples of
the art. Shopping carts have worked without AJAX for years, using
server-side code by submitting to the server and returning the same page
with updated cart information. So there is no question that an
e-commerce site can be written such that it can take money off people
dependent only on their having an HTML web browser and enough funds or
credit to make the purchase.

(Fully client-side shopping carts are one of the worst ideas going and
should _never_ be used.)

There is also nothing inherent in AJAX that will get in the way of this
reliability. Jim Ley's (now famous) XML HTTP request page:-

<URL: http://jibbering.com/2002/4/httprequest.html >

- demonstrates how a standard form submission may be short-circuited
with an XML HTTP request. So a smooth and responsive shopping cart
interface certainly could be layered over a reliable, page-replacing,
server side alternative. AJAX in this context does not have to be
getting in the way of the primary purpose in e-commerce of taking money
off people, giving the best of both worlds; a smooth interface for most
and the ability to take money off all. Additionally, a framework could
be written such that it would make normal page submissions when the AJAX
alternative did/could not work and use AJAX when it could.

So when I visited iconbuffet.com with my IE 6 (which has JScript enabled
but ActiveX disabled in the Internet security zone for obvious reasons)
clicking on the "Add to Cart" buttons told the significant story.
Nothing happened, no errors, no page submission and no shopping cart
update. The site's ability to take my money off me had fallen at the
first hurdle. In e-commerce that qualifies as a complete failure, and
the developer responsible has to bear the responsibility for that
failure.

Now there are people who respond to that type of observation by whinging
on about "target audiences" and how the percentage of people who operate
their browser in non-default configurations (or use unexpected browsers)
is so tiny that refusing their business, through the use of avoidable
technological dependencies, is not important. These responses persist in
part because of the impossibility of making any realistic assessment of
the real (statistical) significance of these (and other) conditions.
Though making an informed business decision about the technologies (and
their dependencies) to use on an e-commerce web site may be
significantly altered by an honest admission that nobody knows what
percentage of customers will be turned away as a consequence of any
single dependency. Business people don't tend to turn down money for no
good reason, or take an overly optimistic view or the un-quantifiable.

On the other hand, in this case these arguments evaporate anyway when
you consider that the "target audience" for web icons (the product being
sold by iconbuffet.com) are web developers. Nowhere is there a group of
individuals more likely to be using unexpected web browser or browsers
in their non-default configuration.

I am not saying that "RJS Templates" have caused this failure, I am
fairly sure that responsible individual was going to fail in this
respect without them, but it does appear that the change from the
original code to the "RJS Templates" code had brushed the consequences
of a particular choice of technology a little more out of sight than it
was previously, to where a trusting individual may repeat this folly in
total ignorance of the fact that they were making a mistake it at all.
I imagine that after I prototype my application a little
more I may run into situations where rjs is more trouble
than it is worth. Maybe not though. They seem pretty good.

> and they do send javascript to the client to update
> various portions of the web page.
Better to send abstract instructions and parameters to the
client (i.e. pure data).

No matter which language you use to define the instructions sent to
the client, both the server and client must know this language.

Of course they don't. If you want something inserted on the client you
can send pure date:-

"InsertX", "what to insert (pure data)", "where to insert it"

- or:-

"Insert" "type of insertion", "what to insert (pure data)", "where to
insert it"

- or:-

"InsertX", ["what to insert (pure data)", "where to insert it"]+

- and have the code that receives it make all the decisions about how it
is going to set about doing the insertion. Or carrying out any other
instruction (or set of instructions) sent.
Why not use JavaScript as this language?
Why not use JSON for the data? But as soon as you put any actual
function call into that transmission you have restricted the flexibility
of the entire system. The only thing that you could do that is worse
than that is to be storing actual executable javascript code in a
database.
I don't see how there is a way to
completely untangle the server and client.

Javascript code is parameterised instructions. That can be abstracted to
instructions and parameters sent as pure data, sent to the client in
that form and easily translated into actions on the client without any
dependency on specific client-side code.

Richard.

[petermichaux]

Richard Cornford wrote:

[AJAX shopping cart]
I agree, very bad idea.

No matter which language you use to define the instructions sent to
the client, both the server and client must know this language.

Of course they don't.

But I still think they do!

If you want something inserted on the client you
can send pure date:-

"InsertX", "what to insert (pure data)", "where to insert it"
I would counter that you have just specified a language or syntax or
format. The server knows to send the data in this fomat and the client
expects data in this format. That seems a language. True that your
proposed format is not dependent on JavaScript but the client would
still need to know what to do with it.

The only thing that you could do that is worse
than that is to be storing actual executable javascript code in a
database.

:D I am storing JavaScript in a database. And I think it is a good idea
in my particular case.
Peter

[sergioafp]

Thomas, I'll try to be respectful. I won't comment on the rest of what
you said because it wouldn't be fair since you already confessed not
knowing the code base.
But the following comment:

[...] Rule of thumb: avoid "this" inside anonymous functions and also in
functions you pass around as references.

Utter nonsense.

Makes sense when quoted out of context like you did. Maybe I expressed
myself incorrectly. What I meant was that, when using classes that
encapsulate AJAX calls and you pass some of the classe's methods to be
invoked in callback situations, you have to be extra careful with the
"this" keyword. The same applies to anonymous methods used as
callbacks. In such situations, as you most likely already know, the
"this" keyword may not represent the same thing as in the original
context, e.g. it may represent the "window" object in some cases.

I hope I clarified it now. Did I mention I can goof things up some
times ? :) I hope you can be a little more patient with me, I'm slow.

- Sergio
http://www.sergiopereira.com/articles/

[Richard Cornford]

pe**********@gmail.com wrote:

Richard Cornford wrote:

[AJAX shopping cart]
I agree, very bad idea.

No, not a bad idea as such. An AJAX dependent shopping cart is a bad
idea. The fact that it can be done with all the interactivity of AJAX
while still not sacrificing the solid reliability of a server-side
shopping cart makes the avoidable dependency the bad idea not the AJAX.

No matter which language you use to define the instructions
sent to the client, both the server and client must know this
language.

Of course they don't.

But I still think they do!

If you want something inserted on the client you
can send pure date:-

"InsertX", "what to insert (pure data)", "where to insert it"

I would counter that you have just specified a language or
syntax or format.

I have proposed an abstract interface. Such an interface needs thinking
about and careful designing. The result can be considered a language, in
the same way as IDL is a language.
The server knows to send the data in this fomat and
the client expects data in this format.
Yes, the format is the contract between the two. Neither may break the
contract but either may satisfy it in any way they can.
That seems a language. True that your proposed format
is not dependent on JavaScript but the client would
still need to know what to do with it.

Yes, but the code on the client is not determined by the format of the
data it receives. You can completely replace the entire client-side code
without the server-side even caring. That is flexibility.

The only thing that you could do that is worse than that
is to be storing actual executable javascript code in a
database.

:D I am storing JavaScript in a database. And I think it
is a good idea in my particular case.

Mechanism in the database? Oh well, time will convince you even if I
cannot.

Richard.

[Richard Cornford]

se*******@gmail.com wrote:

Thomas 'PointedEars' Lahn wrote:

se*******@gmail.com wrote: <snip>

[...] Rule of thumb: avoid "this" inside anonymous functions
and also in functions you pass around as references.

Utter nonsense.

Makes sense when quoted out of context like you did. Maybe I
expressed myself incorrectly. What I meant was that, when using
classes that encapsulate AJAX calls and you pass some of the
classe's methods to be invoked in callback situations, you have
to be extra careful with the "this" keyword. The same applies to
anonymous methods used as callbacks. In such situations, as you
most likely already know, the "this" keyword may not represent
the same thing as in the original context, e.g. it may represent
the "window" object in some cases.

<snip>

I would have objected to that "rule of thumb" if Thomas had not.
Addressing any potential issue with a blanket ban needs a very clear
justification, and you did not provide one. Still have not.

When you write '... the "this" keyword may not represent the same thing
as in the original context ...' you are implying that - this - means
something related to its context (presumably in the source code). While
in javascript the meaning of - this - is determined entirely, and only,
by how a function is called, and determined at the point of calling that
function.

Understanding the rules that determine the meaning of - this - from the
nature of the function call gives the programmer the ability to know
what - this - will refer to in the context of its use, with total
certainty. Informed decisions about the use of - this - are considerably
more valuable than blanket injunctions against its use, even when
qualified with vague categories.

Richard.

[petermichaux]

Richard Cornford wrote:

:D I am storing JavaScript in a database. And I think it
is a good idea in my particular case.

Mechanism in the database? Oh well, time will convince you even if I
cannot.

Ok, I'll bite. What is so bad about JavaScript in the database?

My application is an online store with multiple store administrators.
If two adminstrators are viewing the same product information and one
administrator edits the product info then I store the JavaScript that
will update the any adminstrators page. When the other administrator
polls the server for new updates the server will send back all the new
JavaScript updates that were stored in the database. This is using the
database as a buffer or holding tank since server push is not possible
for me. Sound horrendous? When the whole system of how I am doing this
came to me it really was an "I've got it!" moment. All the code shunk
by more than 50% and became very Rails-ish.

Peter

[Thomas 'PointedEars' Lahn]

se*******@gmail.com wrote:

Thomas, I'll try to be respectful.
And if you read my followup as disrespectful, you have a problem. I simply
strongly disagreed with your statement, providing the same reasons you did
for your opinion: none.
I won't comment on the rest of what you said because it wouldn't be fair
since you already confessed not knowing the code base.
You misunderstood. I said that I (among others) /know/ the codebase to be
junk. That is a huge difference.
But the following comment:

[...] Rule of thumb: avoid "this" inside anonymous functions and also
in functions you pass around as references. Utter nonsense.

Makes sense when quoted out of context like you did.

I do not see where it would not make sense.
Maybe I expressed myself incorrectly. What I meant was that, when using
classes that
*There* *are* *no* *classes* in the programming languages used. That
there are, that they can be created out of the same language, is one of the
misconceptions distributed by the Prototype code. The reason is that its
author did _not_ know what he was doing (using [but] an _implementation_
of an _object-oriented_ programming language with _prototype-based_
inheritance and a _built-in_ constructor mechanism), therefore he invented
a new, seemingly multi-purpose wheel ("Object-oriented JavaScript", as if
class-based OO was the only way) with visible vertices ("initialize" etc.),
and one spoke (almost no feature tests or fallbacks). And because of this,
that wheel breaks more often than necessary. Which is the main reason why
I call it junk (the missing documentation simply adds to this).
encapsulate AJAX calls
There are no "AJAX calls".
and you pass some of the classe's methods to be invoked in callback
situations, you have to be extra careful with the "this" keyword. The
same applies to anonymous methods used as callbacks.

So in essence you say that one should know what one does, something I can
strongly agree with (see above). But that is different from what you had
stated before, hence my objection then.
PointedEars
--
When the power of love overcomes the love
of power, the world will know peace.
-- Jimi Hendrix

[Richard Cornford]

pe**********@gmail.com wrote:

Richard Cornford wrote:

:D I am storing JavaScript in a database. And I think it
is a good idea in my particular case.
Mechanism in the database? Oh well, time will convince you
even if I cannot.

Ok, I'll bite. What is so bad about JavaScript in the
database?

Implementing the changes that are the inevitable consequences of ongoing
maintenance. Ideally an application wide javascript update can be done
by editing one file (usually a JS) in one place. That is quick and easy
(so relatively inexpensive). Going through a database modifying
executable javascript code is either very time consuming or very
error-prone (if automated) or both.

There is also the question of separating data, logic and presentation.
That is generally seen as a good idea, and frameworks have been created
to maximise that separation. Javascript code is logic, or mechanism, to
should not be mixed in with data and it certainly should not be being
put in a place where it cannot easily be seen/modified.
My application is an online store with multiple store
administrators. If two adminstrators are viewing the
same product information and one administrator edits the
product info then I store the JavaScript that will update
the any adminstrators page. When the other administrator
polls the server for new updates the server will send back
all the new JavaScript updates that were stored in the
database.
In any particular order?
This is using the database as a buffer or holding tank since
server push is not possible for me.
Or anyone else over HTTP.
Sound horrendous?
Insufficient information to judge.
When the whole system of how I am doing this came to me
it really was an "I've got it!" moment. All the code shunk
by more than 50% and became very Rails-ish.

The code shrank, or _your_ code shrank? Every line of javascript added
to the database is another line of code added to the system, and a line
of code added in a non-obvious location.

But what I have seen of Rails so far suggests that it is not suited to
an online sore anyway.

Richard.

[petermichaux]

Richard Cornford wrote:

pe**********@gmail.com wrote:

My application is an online store with multiple store
administrators. If two adminstrators are viewing the
same product information and one administrator edits the
product info then I store the JavaScript that will update
the any adminstrators page. When the other administrator
polls the server for new updates the server will send back
all the new JavaScript updates that were stored in the
database.

In any particular order?

In a particular order. I'm not sure what you really want to know.

When the whole system of how I am doing this came to me
it really was an "I've got it!" moment. All the code shunk
by more than 50% and became very Rails-ish.

The code shrank, or _your_ code shrank?

My code.

But what I have seen of Rails so far suggests that it is not suited to
an online sore anyway.

Ok, my jaw dropped with this one. Why wouldn't Rails be suited for an
online store? What do you think is a better alternative? I think Rails
is well suited to an online store because an online store is just a
collection of pages and forms like most other websites. Have you played
with Rails much? It is pretty cool.

Peter

[Matt Kruse]

Richard Cornford wrote:

Ok, I'll bite. What is so bad about JavaScript in the
database?

Javascript code is logic, or
mechanism, to should not be mixed in with data and it certainly
should not be being put in a place where it cannot easily be
seen/modified.

In some cases, editing a simple .js file is painful and time-consuming. For
example, if a full release is required which will require testing and an
install window which might happen only once a week or less. In cases where
the database is much more easily updated than the filesystem, storing js in
the database might be a good idea. I've even seen jsp's stored in the db,
with a process which would retrieve the file and write it to disk before the
app server looked for it. All to be able to release changes without going
through a painful release process :)

I'm not saying it's a general good practice, but there are cases where it is
one solution to a problem.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

Ok, I'll bite. What is so bad about JavaScript in the
database? Javascript code is logic, or mechanism, to should not
be mixed in with data and it certainly should not be
being put in a place where it cannot easily be
seen/modified.

In some cases, editing a simple .js file is painful and
time-consuming. For example, if a full release is required
which will require testing and an install window which might
happen only once a week or less. In cases where the database
is much more easily updated than the filesystem, storing js
in the database might be a good idea. I've even seen jsp's
stored in the db, with a process which would retrieve the file
and write it to disk before the app server looked for it.
All to be able to release changes without going through a
painful release process :)

You are describing something more akin to content management, which
isn't quite the same issue.
I'm not saying it's a general good practice, but there are
cases where it is one solution to a problem.

It may be going too far to say that javascript source should never be in
a database, I am only really saying that javascript source should not be
data for an application. The data may contain statements of behaviour,
but it should not consist of the actual mechanism.

Richard.

[Richard Cornford]

pe**********@gmail.com wrote:

Richard Cornford wrote:

pe**********@gmail.com wrote: <snip>

When the whole system of how I am doing this came to me
it really was an "I've got it!" moment. All the code
shunk by more than 50% and became very Rails-ish.
The code shrank, or _your_ code shrank?

My code.

Which is always appealing to the individual but not necessarily good for
the system.

But what I have seen of Rails so far suggests that it is
not suited to an online sore anyway.

Ok, my jaw dropped with this one. Why wouldn't Rails be
suited for an online store?

Haven't we been discussing how an application of Rails has directly got
in the way of the primary purpose of an e-commerce site; to take money
off people? And how its use is moving the problematic dependencies out
of sight?
What do you think is a better alternative?
It is possible to use any server side technology to create a very poor
end result. Most should also tolerate the creation of a good end result,
but I would think that the most significant factor in achieving that
outcome is how well the developer(s) in question understand what they
are actually doing.

Unfortunately frameworks seem to go a long way towards stopping
developers from understanding what they are doing. Dot NET seems to be a
particular offender at present. There is a regular stream of .NET
developers posting here because they are using some 'component' and want
something extra from it in the browser, but when questioned many of them
don't even seem to appreciate that there is a separation between code
executing on the client and code executing on the server. When people
are shielded from a basic understanding of what they are doing they are
going to find it very difficult to appreciate (or even see) the more
complex issues buried under the surface.

Rails seems to imply that same shielding of details from the developer,
and it has been proposed that Rails is tying itself up with
Prototype.js, which means unreliable client-side code in situations
where the UA is unknown. So a system where the unnecessary dependencies
are implicit and the developer may not even appreciate that they exist,
let alone be in a position to mitigate.
I think Rails is well suited to an online store because an
online store is just a collection of pages and forms like
most other websites.
If that is the reality, and no dependencies on specific client-side
technologies or code-bases are inherent, then yes, that should be
suitable. However, that is not what you have been describing, nor is it
the reality of the example that has been cited.
Have you played with Rails much?
No I have not used Rails at all, nor am I likely to in the foreseeable
future. I do my server side code in Java (and very occasional JScript
ASP), but currently the demand for me to work exclusively on client-side
code is so great that I have not written any Java in the last two years,
and am unlikely to again for at least the next.
It is pretty cool.

"Cool" is so devalued as a categorisation these days that I no longer
regard it as modifying the worth of its subject.

Richard.

[petermichaux]

Richard Cornford wrote:

pe**********@gmail.com wrote:

Richard Cornford wrote:

But what I have seen of Rails so far suggests that it is
not suited to an online sore anyway.
Ok, my jaw dropped with this one. Why wouldn't Rails be
suited for an online store?

Haven't we been discussing how an application of Rails has directly got
in the way of the primary purpose of an e-commerce site; to take money
off people? And how its use is moving the problematic dependencies out
of sight?

This does not seem like a solid argument against using Rails for a
site. Rails makes building many web apps much easier, faster, and with
less code which could mean less bugs and maintenance. A developer must
still pay attention and know what he is doing. No one said that Rails
developers did not need to know what is going on in the background.

Rails seems to imply that same shielding of details from the developer,

I agree with this. Wrapping everything (HTML, JavaScript) in Ruby is
one of the goals of Rails. Like you said, this could lead the unknowing
into creating a bad product. But that is their own responsibility. I'm
happy to have Rails to make my development faster. With or without
Rails I still must understand what is happening. Each developer is free
to use only as much or little of the Rails wrappers as they want. There
is no requirement to use the Rails JavaScript wrappers. However there
are some things that are being developed in Rails that is making using
these wrappers more attractive.
Peter

[bigdadro]

Sergio,

Thanks for being the only person to answer my questions. The rants in
this goup are worse than slashdot. To everyone opposed to prototype:
I'm not completely committed to using it. You wasted 2 pages of time
and server space without any useful insight. A good answer would have
been...rather than use prototype why don't you try this....[code
snipped here].

[Matt Kruse]

bi******@gmail.com wrote:

The rants in this goup are worse than slashdot.
Well that might be true ;)
To everyone opposed to prototype:
I'm not completely committed to using it. You wasted 2 pages of time
and server space without any useful insight. A good answer would have
been...rather than use prototype why don't you try this....[code
snipped here].

This is a place for _discussion_, not a help desk with just questions and
answers.
Even if the spawned discussion isn't exactly what you wanted, it is
nevertheless a good thing.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Bart Van der Donck]

Matt Kruse wrote:

In some cases, editing a simple .js file is painful and time-consuming.
I have the same experiences.
For example, if a full release is required which will require testing and an
install window which might happen only once a week or less. In cases where
the database is much more easily updated than the filesystem, storing js in
the database might be a good idea.
I'ld say it's totally up to the nature of the application, and what the
project specifications consist of. That eventually might include
storage of javascript source code. But I think one should definitely be
careful with such design models, though.

The major concern I would have with this scenario is one of
performance. Javascripts loaded from the filesystem require much less
resources from the machine than a database lookup.

I have numerous js files that are automatically updated by cronjobs.
Those js files mainly hold variables coming from the database;
synchronised once a night and then used for the heavy CPU work during
the day. I don't want to toot my own horn, but I think this is better
practice than querying over-and-back all the time.
[...]
I'm not saying it's a general good practice, but there are cases where it is
one solution to a problem.

I totally agree with that evaluation.

--
Bart

[Bart Van der Donck]

Richard Cornford wrote:

[..]
It may be going too far to say that javascript source should never be in
a database, I am only really saying that javascript source should not be
data for an application. The data may contain statements of behaviour,
but it should not consist of the actual mechanism.

At least in my main domain (Perl/CGI), it's not uncommon to consider
javascripts as dynamical data, generated on-the-fly by the application.
The content of the javascripts then depends on the underlying data
(typically, from a RDBMS) and/or simply on the javascript code that
might be desirable at that moment (eg. alert-window, additional form
checks, extra functions, etc.)

--
Bart

[Tony]

bi******@gmail.com wrote:

Sergio,

Thanks for being the only person to answer my questions. The rants in
this goup are worse than slashdot. To everyone opposed to prototype:
I'm not completely committed to using it. You wasted 2 pages of time
and server space without any useful insight. A good answer would have
been...rather than use prototype why don't you try this....[code
snipped here].

Not true. The responses may not have answered your specific question,
but as has often been said - this is NOT a help desk!

The discusseion was QUITE helpful to me, as some people I work with have
suggested looking into prototype.js, and the discussion provided me with
some insight about the library and its limitations that I would
otherwise not have had.

[bigdadro]

If anyone is interested i found a solid explanation to my question.
http://blog.livollmers.net/?p=17. But.....due to the fact that I asked
a "helpdesk" question and not a valid javascript question this is most
likely a useless article :)

[petermichaux]

bi******@gmail.com wrote:

If anyone is interested i found a solid explanation to my question.
http://blog.livollmers.net/?p=17. But.....due to the fact that I asked
a "helpdesk" question and not a valid javascript question this is most
likely a useless article :)

If scoping of the AJAX response handler function is a problem check out
the Yahoo! UI connection manager. This problem is gone because they
have a scope parameter

http://developer.yahoo.com/yui/connection/#scope

Peter

[Richard Cornford]

bi******@gmail.com wrote:

I've created a new class using prototype.js.
That means nothing to anyone not intimately familiar with prototype.js.
After I make the ajax.request all references to
this.myClassMethodorVariable are lost.
No evidence for that is presented here (including any indication of what
"references to this.myClassMethodorVariable" is supposed to mean).
Does the ajax method blow out the object persistance?
What would you regard as "object persistence"?
I'm fairly new to OOP javascript so could be (and probably
am) overlooking some detail.
Or you are hiding from learning what OO javascript is behind someone
else's library.
Below is the logic of what i'm trying to do.
Demonstrations are more effective than incomplete descriptions.

<snip> var myAjax = new Ajax.Request( this.WSURL, { method: 'get',
parameters: pars, onSuccess: this.myHandler});
In the same way as - this.WSURL - is passed to the method call as a
string value (it is resolved to a value and that value becomes the
argument), - this.myHandler - is assigned to a property of the object
that is the second arguemnt to the mehtod call as a reference to a
function object. Function objects that are assigned to properties of an
object do not know that they have been assigned as properties of an
object (indeed they could not as they may validly be assigned as
properties of any number of (any type/'class' of) objects, as is the
case here where the same function object is a property of your -
myClass.prototype - object, and is also a (onSuccess) property of the
anonymous object passed to the method call.)
},
myHandler: function(ajaxResponse) {
this.myMessage(ajaxResponse.responseText);
},

<snip>

The value of the - this - keyword in javascript is determined entirely,
and only, by how a function is called (and at the point of calling the
function). If it is called as a method of an object (using a property
accessor) then the - this - value will be a reference to that object. If
it is called in any other way the - this - value will be a reference to
the ECMAScript global object.

The - Ajax.Request - method may call the function referred to by -
this.myHandler - as a method of the anonymous object passed to the
method as an argument, or it may call it having assigned a reference to
it to a local variable (through an Identifier). Thus the - this - value
will either be the anonymous object or the global object, but not the -
myClass.prototype - or any instance of - myClass -, it is impossible to
tell without the code of - Ajax.Request -. Neither of the object that
may be - this - have a 'myMessage' property.

Maintaining associations between javascript custom objects and their
method when using the methods as call-back functions is often done with
closures in javascript:-

<URL: http://jibbering.com/faq/faq_notes/closures.html >

Richard.

[bigdadro]

Richard,

Thanks for helping me out with my problem. Being the all knowing
javascript "wizard" you are, you could have at least provided me with
some positive guidance instead of what appears to be ridicule. Keep up
the good work, dude!