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 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? >
