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>

[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**********@gm ail.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**********@gm ail.com wrote:

Richard Cornford wrote:

pe**********@gm ail.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**********@gm ail.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**********@gm ail.com wrote:

Richard Cornford wrote:

pe**********@gm ail.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**********@gm ail.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