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?
