Hi Martin, You are very right, I have mistaken the element. Thank you for your quick answer!
Best regards, A On Mon, Oct 21, 2013 at 1:27 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > 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 > > >
