On Nov 23, 12:47 pm, Aaron Newton <[email protected]> wrote: > I have plans to write a detailed blog post about delegation on the mootools > blog, but I've been busy; maybe this week. > > Anyway, to answer your questions, delegation is not always better. For > example, mouseover/out events are fired whenever you move your mouse across > any element's borders, and attaching delegation to, say, a document full of > links, divs, lists, and images so that whenever you mouseover an element > with 'a.tips' would mean running the selector a LOT. Drag your mouse across
You could reduce this cost by narrowing the scope of the selector: #parent a.tips, for example. > the page and you might run the selector dozens of times. Mousemove is even > worse. > > This isn't to say that mouseover isn't a good candidate, but it's a poor > candidate for an element containing a LOT of elements (like document.body). > Put it on a list of links, like a menu, and it's fine. > > Click events are much better as they don't occur like this. > > Delegation pushes the cost of selectors away from startup and removes the > looping costs associated with $$().each(..addEvent). They also allow you to > alter the DOM and have your behavior apply to any new items that match the > selector. But they aren't always a better solution than addEvent. In > general, I'd say that maybe 70% of the time they are better. Knowing which > one to use is a matter of balancing initialization costs, the event type, > the size of the DOM inside the parent that's getting the event attached, and > the use case. There's no 100% correct answer, though some solutions are > clearly better than others (mousemove for example, is nearly always a poor > candidate). > > > > On Mon, Nov 23, 2009 at 11:48 AM, Rolf -nl <[email protected]> wrote: > > Ok, so on the startup/initialize side of things event delegation is > > (in my case) quite useful. Though when there are exceptions or changes > > to elements I would have to work with (css) classes added to elements > > to prevent certain behaviour (or make it do something different) > > > For example, I could use store/retrieve now to determine wether or not > > to attach (or detach) an event to some element. With event delegation > > I only have Selectors to 'filter', correct? > > > Generally speaking, would you advise to use event delegation whenever > > possible? I mean, if it saves memory compared to when you are > > attaching events to a lot of elements for example. If it doesn't save > > you memory in the end it is "just" quicker (or a clean way) to program > > instead of typing each-loops every time. > > > To me adding a event to stop propagating and prevent dragging of some > > element as soon as you would start to drag sounds a bit like hack. > > Using css classes to determine what to do in some part of the > > application sometimes also feels like hack (as if you are adding style > > bits to an element that you are using just to get some sort of 'state' > > value). > > > Maybe a good example, would you rewrite the Tips class now using > > delegation? Or, maybe because the attach/detach methods are too > > specific it's better to just leave it like it is... > > > On Nov 23, 7:19 pm, Aaron Newton <[email protected]> wrote: > > > Mooshell appears to be broken at the moment, so I can't look at the > > example. > > > But what you say sounds right. > > > > On Mon, Nov 23, 2009 at 9:17 AM, Perrin Perrin < > > [email protected]>wrote: > > > > > In the example drag/drop lock example you could implement a 'lock' on > > an > > > > individual element by adding an event hander directly on the element > > (say > > > > when drag started) and removing it later (when drag completed) that > > just > > > > stops the event from propagating. > > > > > An example:http://mooshell.net/mWYZG/1 > > > > > On Mon, Nov 23, 2009 at 10:48 AM, Aaron Newton <[email protected]> > > wrote: > > > > >> you have the general concept down. if you had a list element (ul) with > > a > > > >> bunch of list items (li) and you added this delegation method: > > > > >> myUL.addEvent('click:relay(li)', function(event, element) { alert("you > > > >> clicked " + element.get('id')) }); > > > > >> Then, if you added any new list item to the list it would get this > > > >> behavior. This is one of the benefits of delegation. If you wanted to > > > >> prevent this from occurring to some of the list items you might give > > them > > > >> all a class and delegate only to those with the class assigned, > > removing the > > > >> class from those you don't want to have the behavior. > > > > >> You can't prevent this behavior by attaching an event or calling > > > >> removeEvent on the li objects, as they don't have events attached to > > them. > > > > >> On Mon, Nov 23, 2009 at 4:10 AM, Rolf -nl <[email protected]> > > wrote: > > > > >>> If I add an event to a collection of elements in a parent using event > > > >>> delegation that it automatically also adds the event on new elements > > > >>> created in that parent? > > > >>> From tests I can say this is true, and I think it's also in the docs > > > >>> "[..] evaluating your code only when the user actually clicks [..]" > > > >>> but just to make sure... Correct?! > > > > >>> I used to have attach/detach methods in several classes that I would > > > >>> run on each element in a collection of elements which aren't needed > > > >>> anymore if I do one addEvent on a parent container using event > > > >>> delegation... > > > > >>> One more thought (not tested yet).. if I would do a removeEvent on a > > > >>> single element in the collection of elements (aka to temporary "lock" > > > >>> a drag/drop possibility by removing the event), is this going to work > > > >>> if I earlier added the event with event delegation to the parent?
