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 in Proto, but for whatever reason, it's been decided
to avoid any dependency on a console device. I very much doubt that
this use case is going to overturn that policy.
On Sep 8, 12:01 pm, Brian Marquis <br...@quotepro.com> wrote:
> 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 difficult than it could
> be. Consider the following modification
>
> someMethod: function(desiredElement) {
> element = $(desiredElement);
> return element.someOtherMethod();
>
> }
>
> Now I can place a Breakpoint on Error in Firebug and instantly know
> which element is causing the problem. Or perhaps even better would be
> a modification to perform console logging if $(element) would return
> null.
--
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
