为什么“自动完成选择”是在配置的“选择”之前调用的处理程序处理程序?

发布于 2024-11-03 09:54:57 字数 603 浏览 1 评论 0原文

我正在构建一个自定义的自动完成小部件,其中我需要覆盖默认的“选择”行为并让它在任何外部附加的事件处理程序之前运行。

$("#input").autocomplete({
    source: ['A','B','C'],
    select: function() {
        console.log("from config.select");
    }
});
$("#input").bind("autocompleteselect", function(event, ui) {
    console.log("from bind()");
});

当我从生成的自动完成结果中选择一个元素时,以下内容将打印到我的控制台:

from bind()
from config.select

我的问题是,为什么?这背后有什么道理吗?在我看来,在给定 autocomplete() “构造函数”的 settings/config 对象中配置的事件处理程序应该首先发生,然后使用 bind() 附加的处理程序应该发生。

我意识到我可以在我的插件中使用bind()来确保我的事件处理程序是第一个运行的,但是它给代码增加了一些混乱。

I am building a customized autocomplete widget in which I need to override the default "select" behavior and have it run before any externally attached event handlers.

$("#input").autocomplete({
    source: ['A','B','C'],
    select: function() {
        console.log("from config.select");
    }
});
$("#input").bind("autocompleteselect", function(event, ui) {
    console.log("from bind()");
});

When I select an element from the resulting autocomplete, the following gets printed to my console:

from bind()
from config.select

My question is, why? Is there some rationale behind this? It seems to me that the event handler configured in the settings/config object given to the autocomplete() "constructor" should happen first, and the handlers attached with bind() should happen afterwards.

I realize that I can just use bind() within my plugin to ensure that my event handler is the first one run, but it adds some clutter to the code.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

恋你朝朝暮暮 2024-11-10 09:54:57

这是因为它在幕后使用了 Widget 对象的 _trigger 函数。

查看下面的代码摘录,您将看到在正常事件触发器 (this.element.trigger) 之后调用 callBack(选项参数中的函数)。

_trigger: function( type, event, data ) {
    var callback = this.options[ type ];

    event = $.Event( event );
    event.type = ( type === this.widgetEventPrefix ?
        type :
        this.widgetEventPrefix + type ).toLowerCase();
    data = data || {};

    // copy original event properties over to the new event
    // this would happen if we could call $.event.fix instead of $.Event
    // but we don't have a way to force an event to be fixed multiple times
    if ( event.originalEvent ) {
        for ( var i = $.event.props.length, prop; i; ) {
            prop = $.event.props[ --i ];
            event[ prop ] = event.originalEvent[ prop ];
        }
    }

    this.element.trigger( event, data );

    return !( $.isFunction(callback) &&
        callback.call( this.element[0], event, data ) === false ||
        event.isDefaultPrevented() );
}

谨致问候,
史蒂芬.

That's because behind the scene it uses the _trigger function of the Widget object.

Check out code excerpt bellow and you'll see that the callBack (the function in your options parameter) is called after the normal event trigger (this.element.trigger).

_trigger: function( type, event, data ) {
    var callback = this.options[ type ];

    event = $.Event( event );
    event.type = ( type === this.widgetEventPrefix ?
        type :
        this.widgetEventPrefix + type ).toLowerCase();
    data = data || {};

    // copy original event properties over to the new event
    // this would happen if we could call $.event.fix instead of $.Event
    // but we don't have a way to force an event to be fixed multiple times
    if ( event.originalEvent ) {
        for ( var i = $.event.props.length, prop; i; ) {
            prop = $.event.props[ --i ];
            event[ prop ] = event.originalEvent[ prop ];
        }
    }

    this.element.trigger( event, data );

    return !( $.isFunction(callback) &&
        callback.call( this.element[0], event, data ) === false ||
        event.isDefaultPrevented() );
}

Best regard,
Stéphane.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文