Hi,
On Mon, Oct 21, 2013 at 2:01 PM, Attila Tarkabak <tarkab...@gmail.com>wrote: > Hello List! > > I can see that Wicket 6 is using jQuery.triggerHandler() for propagating > events like '/dom/node/removing' or '/dom/node/added', which occur when an > AJAX response is processed. Is there a particular reason for not using > jQuery.trigger() instead? > > jQuery.triggerHandler() does not make events bubble up the DOM tree, which > seems counter intuitive with the aforementioned two events. If these events > bubbled, custom JavaScript could listen to them on the <body> and trace > Wicket uses jQuery(**document**).triggerHandler(). The event is not triggered on the added/removed element. This would make things slower for no benefit. > them back to their source using the 'target' property. This would help when > attempting to attach / detach JavaScript instances from elements that are > being replaced. > You can use Wicket global listeners to implement what you need. > > Would it be possible to replace the calls in Wicket.Event.publish() and use > jQuery.trigger() in place of jQuery.triggerHandler()? I think it would make > the life of JavaScript widget developers - meaning yours truly - easier. > > Cases I am especially concerned about: > > <div id="A"> > <p id="B">Foo</p> > </div> > > Let's say I have a custom JavaScript widget attached to "B". If "A" is > replaced, there's no way the widget can be notified, unless it can listen > to '/dom/node/removing' on the <body> and detect that the event.target is a > parent of "A". Then it can detach itself before the replace occurs. > > If you have any suggestions on solving this problem with the current setup, > I am interested. > > Best regards, > Attila >
