In numerous places throughout the Prototype library, the element
parameter is extended and overwritten. This code typically resembles
the following code:
someMethod: function(element) {
element = $(element);
return element.someOtherMethod();
}
For me, at least, this makes debugging more
Hi.
I'm having all sorts of fun with dynamically setting the check in a checkbox.
Which way should I do things?
Initially I thought something like this should work.
$$('#container label
input[type=checkbox][checked]').invoke('writeAttribute', 'checked',
false);
It doesn't.
Instead it seems I
Could somebody advise as to the effort level and any tips for me to
add better support for Prototype working with SVG docs?
The two things I miss the most (so far), are the complete lack of
observe/Event.Handlers capability (perhaps due to XML namespace
difference, since the SVG Events are still
I think the way it is is intuitive to JavaScript developers who know
Document.getElementById(). If the element may return null, then check
for null dammit ;-) ... just as if you were coding directly with w3c
API.
WRT console logging, there are tons of places where console logging
would be useful
Blaine,
It's not my code...
I'm trying to debug other people's work, it's rather irritating when I'm
getting a null pointer exception from code returned via an Ajax call and run
via executeScripts.
I'm not asking to change the behavior or somehow trap the null value and
return something else.
I just finished RC1 of a prototype.js based form generator which will read a
table from a mysql database and generate all the necessary files (html,
javascript, php) to allow you to read, update or insert records into a
table.
This isn't a be all end all tool but it gets the job done and leaves
Hi,
Hmm, I wonder if the original value would still be in the
arguments array???
Nope. `arguments` is *that* magic. If you have, say:
function foo(bar)
...then `bar` is an alias for `arguments[0]` and vice-versa. Writing
to `bar` updates `arguments[0]` and writing to `arguments[0]`