Expand customizable cells to all views

[Azaret]

Q	A
Bug fix?	no
New feature?	rather enhancement
BC breaks?	no
Related tickets	fixes #2120, partially #2043
License	MIT

[Azaret]

WIP

[Azaret]

@vsn4ik I took the liberty to enhance your idea.
I directly attach the event listener to the correct DOM node and use jQuery data() so the DOM is kept clear.

[Azaret]

Attaching the event directly to the node was in my mind for the v2.
But the click function is already less a mess than 2 minors versions ago, so it's safe to make the change now.

[Azaret]

@acrobat Fill free to play around to be sure I didn't break everything.

Some snippet for your amusement:

function callback() {
    var smileys = ['😁', '😋', '😡', '😰', '🙅', '🙊', '🙏', '✌', '🚀', '🚨', '🚧', '🚽', '🉐', '⌚', '☝', '⚽', '⚾', '⛄', '⛅'];
    return {content: '<div>' + smileys[Math.floor(Math.random() * smileys.length)] + '</div>'};
}

$('input').datepicker({
    beforeShowDay:     callback,
    beforeShowMonth:   callback,
    beforeShowYear:    callback,
    beforeShowDecade:  callback,
    beforeShowCentury: callback
});

[acrobat]

@Azaret Thanks for the work! I've tested the code and it looks like it works for all views (cool example btw :D)

@vsn4ik @hebbet Do you guys have time for a review?

[acrobat]

@Azaret Do we need extra tests for this behavior (the changes to the click etc) or is it covered by the current tests?

[vsn4ik]

No, it is bad practice.

[Azaret]

Why ?

[vsn4ik]

If you follow your rule will turn 90 listeners: (4 * 12) + 42 (days) = 90. Is not critical, it is possible to leave.

[acrobat]

Is this comment fixed?

[Azaret]

Yeah I though about it the other day and it hit me what @vsn4ik was talking about.
The issue is that by design it is not easy to catch the event when the DOM is customized.
Comprehensive drawing:

Before it was easy, you can bind on the container, and get the source of the event with currentTarget.
Now currentTarget will return the custom DOM nodes instead of the td cell.

The easiest and safest way is then to bind the event to the cell, so target will equals the cell, always.
If we keep the event bound to the container, it mean we'll have to lookup for the cell between the target and the currentTarget.

So the question is, which is the best performance wise between binding 90 events or recursively find a DOM element.

[acrobat]

Ok that explains a lot! So we should go for the 90 events for now? What do you think @vsn4ik?

[acrobat]

Ping @vsn4ik

[acrobat]

@Azaret @vsn4ik I'm going to release RC2 in the next few days. If this is complete then it will be in RC otherwise we will do another RC when this is merged!

[Azaret]

Well it looks clear to me, I'm waiting @vsn4ik input on his remarks.

[acrobat]

Hmm he had posted a comment, but it looks like it was deleted. So indeed wait for @vsn4ik for his feedback

[brandon-burciaga]

When is this expected to come out? According to the docs, returning an object with a content key in the beforeShowDay method should allow me to change the content, however it does not work. I can disable a day fine with a boolean, just can't set content. @Azaret @acrobat @vsn4ik

edit* I realized this isn't enabled in the version I am using (1.6.4) and I could change the docs based on version :) thanks to everyone contributing to this

[acrobat]

@Azaret sorry to ping you again! But any more work needed here? If I understand your comment above correctly "90 events" choice we have to make is good enough for now?

If we can agree on some solution for this would be nice, this way I can put out a RC2 ( and hopefully quite quick a stable release)

/cc @vsn4ik