showValidity的实现 about esui HOT 22 CLOSED

把showValidity丢到InputControl.prototype下去

我觉得也是这样比较合理

问题：默认的实现怎么样的合适，在InputControl后面插一个label元素放内容？

现在所有的系统应该都是这样的。默认插哪，请几位merge下beidou、clb、union。我觉得，需要一个属性，指示错误信息容器。（id?）

from esui.

我觉得label统一加ui-validation-error-message的class，控件的main默认加ui-validation-error的class，放就直接作为控件的main的nextSibling，业务线可以重写来定制

from esui.

我觉得也行。之前主要担心提示label可能需要在下一行的问题。下一行就css定义好了。
默认用啥？label？span？

from esui.

嗯，目前这边基本就是这种实现方案，但有时确实需要能够具体指定容器，比如输入框后面是带单位的，但错误提示是需要放此单位后面的。InputControl是否可以添加一个公共属性 容器id， 不指定就按默认的来。默认span?

from esui.

@kitemao 的说法很有道理，但我个人有一个担心的问题：如果因为验证而放一个属性在控件上，那么很可能就有人textbox.set('validationLabelContainer', 'abc')，但由于ESUI的设计是一有set就会送到repaint上，如果repaint实现的不好，可能会导致重绘制（比如有些控件，他假设任何属性变化都会完全重刷main中的内容，其实对于部分控件这个逻辑也是合理的）。

因此，我个人不希望通过属性的方式来解决这事，我这边有一个比较“绕”的方法，抛砖引玉，想看看各位有没有进一步的想法：

InputControl.prototype.showValidity = function (validity) {
    if (!validity.isValid()) {
        var message = '';
        var states = validity.getStates();
        for (var i = 0; i < states.length; i++) {
            var state = states[i];
            if (!state.getState()) {
                message = state.getMessage();
                break;
            }
        }

        // 调用另一个抽象方法
        this.showErrorMessage(message);
    }
};

// 一个默认实现
InputControl.prototype.showErrorMessage = function (message, container) {
    var id = helper.getId(this, 'validation-error-message');
    var label = lib.g(id);
    if (!label) {
        label = document.createElement('label');
        label.id = id;
        label.for = this.main.id;
        label.className = 'ui-validation-error-message';
    }

    // 默认是没有container的，直接放在后面
    if (container) {
        lib.g(container).appendChild(label);
    }
    else {
        this.main.parentNode.insertBefore(label, this.main.nextSibling);
    }
};

当你想要把验证信息放到特殊的容器里时，你得重写掉showErrorMessage这个方法：

textbox.showErrorMessage = function (message) {
    InputControl.prototype.showErrorMessage.call(this, message, 'xxx');
};

这么做的优势是没有属性来影响控件的整个渲染，缺点是因为没有属性，不能在HTML里配置这个容器了

from esui.

嗯，这种方法可以哈。不过有此需求都要override此方法， 意识上总感觉对使用者来说太麻烦了。不过由于ui规范默认是放到后面的，这种需求倒不是很多，也是可以的。

textbox.set('validationLabelContainer', 'abc')，但由于ESUI的设计是一有set就会送到repaint上，如果repaint实现的不好，可能会导致重绘制（比如有些控件，他假设任何属性变化都会完全重刷main中的内容，其实对于部分控件这个逻辑也是合理的）

嗯，确实有这种问题，即使饶了过去，是否还会有类似的需求？要不加个类似ignoreStates的配置？此配置中的值set的时候不进行repaint？

from esui.

1. 感觉会越搞越复杂
2. 而且这种“不管更新啥都重刷”的控件，本身会直接重写repaint，不使用helper.createRepaint，这样这属性用不到。要是在setProperties地方吞，感觉影响面有些大

from esui.

嗯，这样是会给整复杂了

from esui.

先问一个问题，为啥是validationLabelContainer，不是validationLabel
然后是一个逻辑问题：showValidity应该考虑，如果验证通过时，需要隐藏错误信息

接下来，进入正题：

我觉得，排除默认需求，现在我们遇到最多的需求是：需要指定错误信息显示的label元素。

所以：

1. 应该放出{HTMLElement}createValidationLabel()方法，而不是showErrorMessage方法。至于error message
   是怎么show和hide的，不关心。想玩的话，自己重写showValidity方法好了。
2. 属性的支持，我觉得可以搞。因为，95%＋的情况，用户不会在运行时去换label。我是没见过。所以，如果只是在创建控件的时候传入validationLabel，和repaint就无关了。

还有，我e文不好，为啥有时候Validity有时候Validation

from esui.

为啥是validationLabelContainer，不是validationLabel

因为容器可以一开始就在HTML中写死，但label是动态创建的，不好直接通过配置搞定

如果验证通过时，需要隐藏错误信息

这个显然需要，showValidity在验证通过时也会调用，会处理隐藏

createValidationLabel方法

如果要有这方法，我建议叫getValidationLabel，但这样更不好用属性配置了

属性的支持，我觉得可以搞

如果要搞，就应该用container，而不是label，毕竟label要实用实创建，一直在显得有点奇怪

from esui.

因为容器可以一开始就在HTML中写死，但label是动态创建的，不好直接通过配置搞定

但是如果label是动态创建的，那它可能在不同的使用场景下，被插入到container的不同地方，这样支持起来就麻烦了。不知道我理解的对不对

from esui.

其实现在我们有这样的需求，随着输入提示还能输入x个字符。

这个功能从我的角度来看，应该复用showValidity来做，这也意味着，其实我们会需要动态的实时验证，那么肯定有一个label放在那。

我的理解是，方法叫getXxxLabel，那这个方法的作用是创建/或拿已有的label，放进应该在的位置，返回，所以这点上感觉没关系

from esui.

放进应该在的位置这个行为，是次次做？

from esui.

内置的实现情况下，只有第一次getXxxLabel的时候会做，后面的几次就不搞了，当然重写getXxxLabel就能每次移动。

不过也有个问题，如果不需要验证信息了（验证通过且没有成功信息），那么这个label不删？

from esui.

不删吧，而且我觉得visibility比较好。

1. 更上层不需要reflow
2. 本身因为验证信息造成页面抖动也是不合理的

from esui.

认可visibility的方案，那么我们现在的接口是getValidityLabel和showValidity吗？因为label是延迟创建的，所以不能用属性来配置，只能方法覆盖。

如果OK的话，我去执行

from esui.

整理下我的个人观点：

1. 验证信息的显示元素，用户应该只有一次机会指定。
2. 如果用户不指定，则控件在相应的时机（render时，或者第一次显示错误信息时），创建显示元素，并append/insert到相应的地方
3. 如果支持通过属性指定，那么该指定是不可变更的，控件在相应的时机不创建显示元素。
4. 如果支持用户自定义getValidityLabel方式，则该方法应负责：创建显示元素，并append/insert到相应的地方（这里需要处理，不重复创建），然后返回它。也就是说，控件默认的getValidityLabel方法，应该有其默认实现。相应的时机仅调用该方法。
5. 提示还能输入x个字符，这种需求，其实并不算验证，所以不建议走showValidity的逻辑。如果想使用ValidityLabel，自己的实现里，拿getValidityLabel

from esui.

因为label是延迟创建的，所以不能用属性来配置，只能方法覆盖。

如果创建的validityLabel是挂在控件实例上的，并且与用户传入的属性名一致，其实是能做到属性配置的。
当然。是否支持属性配置，我并没有太多意见。这块实现成本虽然不大，却也没有非要支持的理由。

from esui.

那就是这样：

• validityLabel指定显示信息的元素的id，只读，实例化时可指定
• getValidityLabel默认用validityLabel获取元素，如果没有validityLabel属性，创建一个，放到主元素后面，加上id，再把id赋值给validityLabel
• 由于可以指定validityLabel，则getValidityLabel()可能拿到null，showValidity需要注意

还能输入x个字符，我对这个功能的理解其实是“验证通过”后的一种信息反馈，当超过x个字符后，其实会使用error样式显示“已超过y个字符”，所以我觉得这个是对验证体系的一种扩展，扩展点在于：

• 支持即输入即验证（控件本身的职责）
• 支持验证成功的提示信息（很多验证框架有，而我们没有）
• 支持动态的验证信息（这个无所谓，大不了实时改xxxMessage）

from esui.

赞！

关于支持验证成功的提示信息，我们其实也可以扩展。我们现在的ValidityState包含state和message，其实是分离的。但是validityLabel的样式classname可能就要随着验证是否通过，每次show时做一些变化。 @otakustay 看你想不想搞了，哈哈

from esui.

OK，因为验证成功提示信息这东西，其实全局重写showValidity，再规定一个属性的名字就成，所以我不是很在意，业务线也能做

我先按上面说的去搞label问题

from esui.

在 4e9dc88 中实现，求review

from esui.