Prototype: Core Google Group

Re: [Prototype-core] Re: Class#create and throw new Error()

2009-11-08T00:40:44Z

Oops, my bad.

Ilya Furman

Re: Element#insert taking multiple contents

2009-11-07T23:22:22Z

Agreed. Have often thought that this would be a useful addition.

Element.insert(part1, part2, part3)

and

Element.insert({
top : [part1, part2, part3]
);

should both be able to be implemented without too much hassle and
would provide some really valuable functionality - let's make it

Re: Class#create and throw new Error()

2009-11-07T14:44:23Z

Hi,

The initializer is called "initialize", not "initialization" (see the
docs[1]). Your code throwing the exception isn't being called, hence
the exception not being thrown. If you use the correct name, the
exception is thrown and correctly propagates out to the code creating
the object.

Class#create and throw new Error()

2009-11-06T16:23:05Z

Hello!

I'm wondering, why class instance is being created while
initialization method throws an error?

var C = Class.create({
initialization : function() {
throw new Error('Hey, you can\'t have any instances of this
class!')
},
foo : 'foofoo' ,
bar : function() {
alert(this.foo)

Re: Element#insert taking multiple contents

2009-11-06T07:54:07Z

Probably easier to implement using an Array:

container.insert({
top: [part1, part2, part3],
bottom: [part4, part5],
after: "<p>Hello World</p>"

Re: Multiple eventName's for Event observe?

2009-11-04T09:10:55Z

I have to agree with Allen on this one. The mentioned usage would work
perfectly for me.

Re: Element#insert taking multiple contents

2009-11-06T13:05:53Z

I had made a list of useful Element#insert goodies here -
[link]
There was a ticket for this
[link]
but as far I understand major changes to Element.insert are planed for

Element#insert taking multiple contents

2009-11-05T20:53:30Z

Would it be reasonable to implement it so that Element.insert takes as many
content as you pass it? This will exclude insertion points of course...
container.insert(part1);
container.insert(part2);
container.insert(part3);
would be:
container.insert(part1, part2, part3);
Thanks.

Re: [Prototype-core] Re: Element.classNames()

2009-11-03T22:04:26Z

2009/11/3 Andrew Dupont <goo...@andrewdupont.net>:
OMG! My excuse is I'm 42 years old and going bald. Enough to give
anyone brain farts!

Re: [Prototype-core] Re: Element.classNames()

2009-11-03T18:07:23Z

Nope — that's the notation for returning an array of strings.
I second this request.
Cheers,
Andrew

Re: [Prototype-core] Element.classNames()

2009-11-03T09:54:48Z

2009/11/2 Sedul <sedul...@gmail.com>:

According to [1], you will get a string back, not an array of strings.

Can you supply an example page?

Richard.

[1] [link]

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"

Element.Layout class coming in 1.7. Need feedback!

2009-11-03T06:12:05Z

Yes, the Element.Layout class is imminent. In fact, it's already here.
Take a look:

[link]

I've posted layout code before; this is the same code with a couple
more refinement passes. You can read the included PDoc comments to get

Element.classNames()

2009-11-02T18:38:55Z

I am using Prototype 1.60 and when I call classNames() on an element,
it returns me the element and not an array of Strings?

Re: innerText vs textContent

2009-10-23T23:14:14Z

That's actually one big can of worms. Here's a full explanation, if
you're interested — [link]

Most robust solution is actually not `textContent` and not
`innerText`, but recursive iteration of children (text) nodes. However

innerText vs textContent

2009-10-23T21:15:58Z

Hey guys,
Unless I'm mistaken, there seems to be cross browser incompatibility issue
with innerText and textContent. innerText is IE (and everyone else I
believe), and textContent is Firefox (only, i believe). In anycase,
wouldn't it make sense for Prototype to smooth this out?
Element.getText() perhaps?