Don't mind a bit. Enjoy. As a final note: I will consider the addition of a numeric value for the delay, however, that could just as easily be accomplished by the registering method itself (i.e. the listener is itself a setTimeout with a specific delay).
Also, I would not mind a bit if Object.inherit were included into Prototype, but was just stating that it should not cause any of the existing methods to change. Good discussion, this. On 4/3/07, Yanick <[EMAIL PROTECTED]> wrote: > > > On 3 avr, 00:16, "Ryan Gahl" <[EMAIL PROTECTED]> wrote: > > Ah ok. Just a slightly different approach. I would argue that the > > EventPublisher model seems a bit less cumbersome. For instance, the only > > class in my model that needs to extend from EventPublisher is the class > that > > is to fire events (subscribers need not extend themselves). The > subscribers > > can then simply register a method (any method) to listen for a specific > > event (any event). So mine is more method-centric where your > implementation > > is centered on registering entire object (which must have a specific > method > > defined to be valid). > > > > I'm sure there are pros and cons to both approaches though. > > > > And I can see the benefit of your approach. If I understand it well, > EventPublisher may be used as global event dispatcher or a base class > for an observable object (am I right ?) In any case, the later may be > used both ways. > > Though, if I may, I would suggest modifying the attachEventHandler's > third parameter to be either boolean or numeric ; this way, one could > specify the async delay to wait before fireing the method of the > handler. In my implementation, I cancelled any pending notifications > because I need to have a system that can support multiple > modifications from user input without notifying observers multiple > times (for a list selection system that syncs with the server). > (Perhaps adding a fourth parameter to flag multiple delayed > notifications or not.) > > But I think we fall off-topic now. I appreciate the comments and > suggestions your proposed, and even if you think that Object.inherit > (or perhaps Class.inherit ?) should not be part of Prototype, I would > think that I will add this feature to a script called prototype- > extra.js that I use in my project for the moment. That is if you don't > mind of course. > > -yanick > > > > > -- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
