prototype.js object persistance

[petermichaux]

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]

I meant I haven't encountered Rails bugs not
Prototype.js bugs.

Too many negatives to parse.

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?

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]

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.

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/2005/12/01/real-world-rails-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.

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]

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?

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/2005/12/01/real-world-rails-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.


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]

[AJAX shopping cart]

I agree, very bad idea.

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.

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]

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

But I still think they do!


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.

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]

(e-mail address removed) wrote:

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

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]

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

 

[Richard Cornford]

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]

(e-mail address removed) wrote:


In any particular order?

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

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]

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.

 

[Richard Cornford]

My code.

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

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.

 

[Richard Cornford]

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.

 

[petermichaux]

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]

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.

 

[Bart Van der Donck]

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 Van der Donck]

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