prototype.js object persistance

[bigdadro]

I've created a new class using prototype.js. After I make the
ajax.request all references to this.myClassMet hodorVariable 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.prototy pe={
initialize: function(fm) {
//Static Variables
this.myMessage = 'hello';
this.myName = 'Nick';
this.frm = fm;
this.WSURL = '/some/Server/script';
this.frm.onSubm it =
this.submitForm .bindAsEventLis tener(this);
},
submitForm: function(evt) {
var pars = myMessage;
var myAjax = new Ajax.Request( this.WSURL, { method: 'get',
parameters: pars, onSuccess: this.myHandler} );
},
myHandler: function(ajaxRe sponse) {
this.myMessage( ajaxResponse.re sponseText);
},
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('somefo rm');</script>

[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**********@gm ail.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'+someO therVar+'").stl ye.visibility') ;

instead of:

document.getEle mentById('someV ar' + someOtherVar).s tyle.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.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Ian Collins]

pe**********@gm ail.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******@hotma il.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/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Ian Collins]

Lasse Reichstein Nielsen wrote:

Ian Collins <ia******@hotma il.com> writes:

I don't think there is another way, a JSON response is the textual
representatio n 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******@hotma il.com> writes:

Lasse Reichstein Nielsen wrote:

Ian Collins <ia******@hotma il.com> writes:

I don't think there is another way, a JSON response is the textual
representati on 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/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

pe**********@gm ail.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**********@gm ail.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.protot ype.call and
Function.protot ype.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.ne t>, dated Sat, 27 May
2006 14:45:31 remote, seen in news:comp.lang. javascript, Ian Collins
<ia******@hotma il.com> posted :

I don't think there is another way, a JSON response is the textual
representati on 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("retur n "+S)
Ob = Fn()
alert(Ob.X)

And
function Obj(St) { return new Function("retur n "+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.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.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/