[Prototype-core] Inheritance changes

[Trevan Richins]

I just saw that there were some more changes with the inheritance code.  
I'm wondering how stable is the code.  Meaning, if I start working on a 
project and use the current inheritance code right now, what probability 
is there that I'll need to rename functions (addMethods) or change 
function calls (such as changing the $super construct)?

Thanks,

Trevan

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---

[Prototype-core] Re: Event methods' bug in Internet Explorer

[Tom]

Matt,
   it definitely does fail in IE, because stop is implmented as

  stop: function(event) {
event.preventDefault();
event.stopPropagation();
  }

  preventDefault and stopPropagation are 2 of the functions added to
the Event object in IE when it is extended so they dont exist on the
native IE event passed.

Tom

On Oct 9, 1:54 pm, Matt Foster [EMAIL PROTECTED] wrote:
 You sure that will fail?  I am pretty sure the static event methods
 should all work with a regular event object.

 Isn't it just for convenience, like the Element methods that they put
 Evethe method in as a property just for the syntactic sweetness?

 Also I agree with Mislav, inline event handling is horrible practice.
 Gather your elements and apply listeners, similar to how you avoid
 inline markup because of CSS, now you can avoid inline markup for
 javascript behavior because of prototype.  I find myself using the
 same selectors in these two technologies constantly and i'll tell you,
 when you come back to it a few months later you'll be happy.

 Cheers,
 Matt

 On Oct 2, 8:26 am, Mislav Marohnić [EMAIL PROTECTED]
 wrote:

  On 10/2/07, Viktor Kojouharov [EMAIL PROTECTED] wrote:

   The above snippet will cause an error in IE due to the reason that the
   event is never extended, since it doesn't go through the observe
   wrapper.

   A possible solution for this is to use the old syntax of
   Event.method(event) inside prototype itself. Or call
   Event.extend(event) at the beginning of each method.

  Exactly. Or simply return false when you are using inline event handling.
  You shouldn't use inline anyway, it's bad practice.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---

[Prototype-core] Custom events are now namespaced; contentloaded is now dom:loaded

[Sam Stephenson]

A small but important change was made to custom events in [7835] (http://dev.rubyonrails.org/changeset/7835 
): all custom event names must now include a namespace.  This is our  
solution to the problem of custom event names conflicting with non- 
standard native DOM events, such as mousewheel and DOMMouseScroll.


Prior to this change, Prototype treated only the event names present  
in the Event.DOMEvents array as native DOM events.  Now, Prototype  
looks for the presence of the namespace delimiter -- a single colon --  
to determine whether you're observing a custom event or a native event.


You'll need to update any code that uses 1.6.0_rc0's contentloaded  
event to use its new name, dom:loaded.  You'll also need to give  
namespaces to any other custom events you may be firing or observing.   
We suggest using singular nouns for namespaces, and past-tense verbs  
for the event names (e.g. effect:queued, widget:activated, and so  
on).


-sam



smime.p7s
Description: S/MIME cryptographic signature