Improvement of _on_dbl_click behavior ?

Scheduler Javascript
#1

Hi,

I share with you my comment about scheduler._on_dbl_click() behavior.

In this method, right away the processus is stopped by the next condition, if it returns true :

if (this.config.readonly || !src.className) return;

In fact, having no className supposes that the triggering HTML element (e.<target|srcElement> or given src as param) is not a relevant container to be processed.

But I found one case where that could be usefull if this method could give a chance to theses kind of containers.

For example, a marked timespan created by passing in html property some HTML tags without CSS classes.
With this kind of marked timespan content, double-clicking on an child like “

My timespan content
” will trigger the _on_dbl_click() method but process will be stopped right away, where as we are in a container which could trigger an event creation attempt.

By extension, the same case can be found with an event in which some HTML tags could be added, in text property for example. Double-clicking on the precise HTML content will trigger the method but an edition process will not be launched.

All that to say it could be convenient that this method, instead of doing directly a “return”, check if the element has a parent to propagate the processus.

A simple idea (copied from the default: of the method switch/case):

if (this.config.readonly) return; if (!src.className) { if (src.parentNode && src != this) { return scheduler._on_dbl_click(e,src.parentNode); } return; }

Else, perhaps just do not test className existence at the start of the method and add an empty case in the switch, like :

case "": if (src.parentNode && src != this) { return scheduler._on_dbl_click(e,src.parentNode); } return; break;

Or even simpler let the “default” swicth/case behavior doing the trick, by eventually just checking if name is empty before trying to get the dblclick_() method existence.

NB : But what about side-effects, the famous question :slight_smile:

#2

I had a doubt about my comment on event text property, but it found the sandbox with the demo “Styling events with templates” ( docs.dhtmlx.com/scheduler/sample … lates.html ), in which the event’s text looks like :

Text: <b> Cirque du Soleil Varekai</b> <br> Descr.Royal Albert Hall

Clicking on HTML tag “B” content does not trigger the waited event, instead of text around, free of tags.

#3

Hi,
thanks for your suggestion!
The latest available for download version has an improved method:

if (this.config.readonly) return; var name = (src.className||"").split(" ")[0]; switch(name){ ... }
The online-samples still need to be updated…)

#4

Hi SergeM, I will try that, thanks.

#5

Hi SergeM,

In fact, that works in version 4.0.1.

However, an improvment could be to add the src parameter when calling the found custom dblclick_name, instead of just give the native event (e).

In this way, custom dblclick methods can know (and use) the same parameter as its caller : scheduler._on_dbl_click(e, src).
So, it could be :

var t = this["dblclick_"+name]; if (t) { t.call(this,e,src); // instead of t.call(this,e); }

In my test, in my custom method I want to check some attributes of the HTML element which has triggered the event (after propagation) but the native event in parameter gives me the first HTML element (src = e.target||e.srcElement) and not the one detected in _on_dbl_click() when was called my custom method.
Because the HTML element (src) is not the one I wait, I naturally performs a scheduler._on_dbl_click(e,src.parentNode) which produces a recursive loop in JS (indeed, if my custom method was called thanks to the parent of the dblclicked element, by calling back the event by giving to it the parent of the dblclicked element it call my method again…and again… and again).

Not sure to have been really explicit ! Hope it was understandable :slight_smile: