关于控件创建时的各来源的参数的优先级 about esui HOT 8 CLOSED

原则

这个问题，我整理标准草案的时候漏写了，是我的疏忽。

我的设想是：永远是用户通过JS传的参数优先，无论是new时还是运行中set时。

实现

对于构造函数，初始化options的时候，如果满足下面条件，才从main上读：

1.属性不存在
2. 有main时

from esui.

简单来说就是

1. 默认值
2. 从main上拿来的值
3. 构造函数传进来的值

然后按优先级由低到高给合在一起，再进行后续的逻辑对吧？

那么我建议控件里加一个抽象方法getOptionsFromMain，然后helper.init来完成这件事

from esui.

然后按优先级由低到高给合在一起，再进行后续的逻辑对吧？

对的，我也是这么觉得。

我的建议是：增加个initOptions(control, options, defaultOptions)吧，在里面做getOptionsFromMain呗。helper.init现在是存在的，我觉得可以helper.init调用initOptions

from esui.

可以，但initOptions这个方法是返回options还是直接往自己身上加了？如果是前者，这名字不适合……

from esui.

当然是后者咯

from esui.

我重新整理了一下，其实一共是有4个层级的，优先级 从低到高 依次是：

1. 默认的选项
2. 从main上取得的部分选项，如href之类的
3. 构造函数传进来的选项
4. 从main上取得的只读的固定的选项，如mode、tagName之类的

最后一个有点特殊，因为有些属性是有main了以后就固定了的，比如<input>元素的type属性，这些东西是不能被构造函数传进来的参数所覆盖的。

我写了一下Label，大概是这样一个逻辑， @errorrik 看看对不对：

Label.prototype.initOptions = function (options) {
    options = options || {};

    var defaults = {
        tagName: 'span'
    };
    if (options.main) {
        var extracted = {
            content: options.main.innerHTML
        };
        require('./lib').extend(defaults, extracted);
    }
    require('./lib').extend(defaults, options);
    // 如果已经有对应的元素，则`tagName`是只读的不可被覆盖
    if (options.main) {
        defaults.tagName = options.main.nodeName.toLowerCase();
    }
    this.setProperties(defaults);
};

from esui.

嗯，没问题，4的情况貌似很少会出现。

from esui.

关于构建时的顺序已经实现，按new -> createMain -> initOptions来，initOptions中已经不需要options.main的判断了

from esui.