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]

(e-mail address removed) 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?

 

[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]

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

 

[Randy Webb]

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

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 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.

 

[Thomas 'PointedEars' Lahn]

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]

o0JoeCool0o wrote:




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.

 

[petermichaux]

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]

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]

(e-mail address removed) said the following on 5/26/2006 10:13 PM:

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'+someOtherVar+'").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.

 

[Lasse Reichstein Nielsen]

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

 

[Ian Collins]

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

True, but what advantage does that offer over eval?

 

[Lasse Reichstein Nielsen]

True, but what advantage does that offer over eval?

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

/L

 

[Richard Cornford]

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]

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 <[email protected]>, dated Sat, 27 May
2006 14:45:31 remote, seen in Ian Collins

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.

 

[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]

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