Hi Martin
> I think Igor said the opposite - bind on document with child selector:
> $(document).on('click', '[data-w-click]', handler);
I probably miss something somewhere in the explanation, then... Sorry for
the confusion!
> Behavior#bind(Component) gives you a reference to the component. No need
to
> pass it as ctor parameter.
Absolutely, and better because we can automatically know whether the
component is-a [web]page or another component...
> According to this article it is better to bind on the table than on the
> document.
> At least this is how I read it.
Yes, me too, that's what I tried to say... (Summer evening's agenda does
not helps to say something intelligent/understandable during the day... :s)
Anyway, I will try to look at your implementation asap and if possible
provide my own answer to your questions and try to help you on this topic
because it is an important feature for me (also)...
Best regards,
Sebastien.
On Wed, Jul 31, 2013 at 3:04 PM, Martin Grigorov <mgrigo...@apache.org>wrote:
> Hi Sebastien,
>
>
> On Wed, Jul 31, 2013 at 2:37 PM, Sebastien <seb...@gmail.com> wrote:
>
> > Hi,
> >
> > I agree with Igor. Just have to take care that binding to document is
> not a
> > default behavior for all bound events, and that it should be use with
> care.
> >
>
> I think Igor said the opposite - bind on document with child selector:
> $(document).on('click', '[data-w-click]', handler);
>
>
> > (IMHO, the javadoc should be enough)
> > Martin, I unfortunately did not had the chance to have a look at your
> code
> > now... :s But, if it not the case, if think EventDelegatingBehavior
> should
> > have a constructor that take a component (the datatable for instance) as
> an
> >
>
> Behavior#bind(Component) gives you a reference to the component. No need to
> pass it as ctor parameter.
>
>
> > argument so the event can be bound it it instead of the document (by
> > getting its markupid as the selector)...
>
>
> > [quote]
> > Here is another important tips "*Attaching many delegated event handlers
> > near the top of the document tree can degrade performance*". For best
> > performance, attach delegated events at a document location as close as
> > possible to the target elements as done in above jQuery code
> > [/quote]
> >
> >
> >
> http://jquerybyexample.blogspot.com/2013/04/direct-vs-delegated-events-with-jquery-on-method.html
>
>
> According to this article it is better to bind on the table than on the
> document.
> At least this is how I read it.
>
>
> >
> >
> >
> > I think events delegation would be a great addition anyhow...
> >
> > Best regards,
> > Sebastien.
> >
> >
> From the discussion so far I see these two issues which need to be solved
> before starting make changes in the code:
>
> 1) it must be possible to use event delegation on "the table", not only on
> the document
> 2) if the ajax attributes are stored in data-w-eventName attribute on the
> element then we need to figure out where to store the Ajax call listeners'
> functions
>
>
> For 1) I see it as a new Ajax request attribute - bindOnComponent = true
> If the attribute is 'false' then the event will be bound on the document
> instead and will use event delegation.
> This way all <td>s can return false, and the <table> can return true to
> handle the bubbling event (and stop it, because otherwise it will be
> handled twice when the event reaches the document)
>
> For 2) We can introduce global registry (e.g.
> Wicket.Ajax.Handlers[markupId][handlerType] =>
> Wicket.Ajax.Handlers["someId12"]["success"] = function(...) {...}).
> So the "global" handler (bound on the table or on the document) can use the
> specific Ajax call listeners for the clicked element with attribute
> 'data-w-eventName'
>
> WDYT ?
>
>
