painters模块 about esui HOT 26 CLOSED

第一个代码例子错了，传入的参数不是数组

from esui.

关于几个内置的painter

1. 指定{string=}member不好吧，不如指定{HTMLElement=}element？
2. 缺少attribute和property的painter
3. delegate会不会死循环？

关于示例

缺少一个如果painter搞不定，需要自己写绘制逻辑的示例。或者，用unnamed painter？

关于问题的问题

painter到底是通过OO实现还是函数式实现好

都行，functional确实更清爽

有些控件，其实是存在多个属性其实对应一个元素的更新的，比如Select的selectedIndex和rawValue，这种通常通过setProperties里额外处理，去掉其中一个属性来实现。但是painter是不是需要支持多个属性的管理，即多个属性更新一个或多个时，执行一次paint

Select的示例里有下面这一段，说明paint方法是可以复用的吧。

{
    name: 'rawValue',
    paint: updateValue
}

from esui.

第一个代码例子错了，传入的参数不是数组

没有错，我把createRepaint的参数改成不定长了，因为我发现事实上创建个painters数组也就是为了传给这方法，为啥不直接调的时候给多个得了

指定{string=}member不好吧，不如指定{HTMLElement=}element？

painters是在 类型声明 的时候用的，而HTML元素是在 实例运行 时候才出现的，因此这个不现实。

缺少attribute和property的painter

因为暂时没用到所以就没加了。这个模块不属于UI标准的一部分，纯粹是ESUI这单个项目的辅助模块，随时有需要，只要有通用性，都可以往里加。

delegate会不会死循环？

基本上delegate都是往下代理的，只要引用没循环（比如别delegate到parent上去）就不会死循环，要是引用循环了还delegate过去似乎是控件实现的问题。

缺少一个如果painter搞不定，需要自己写绘制逻辑的示例。或者，用unnamed painter？

rawValue和disabled就是普通painter搞不定的情况，就是缺少用painter（哪怕自定义的）也完全搞不定的时候，事实上是有的，就是场景不多见，正好Select控件也没用上。作文档时补上，这里主要是讨论……

Select的示例里有下面这一段，说明paint方法是可以复用的吧。

确实是可以利用的，当然Select的源码里，updateValue只用在这一个地方（只是因为实现有点长，不写匿名函数了），一般来说paint方法没有啥复用价值，因为现有体系下，事实上所有的set最终都会转到repaint上，而repaint是一段一段通过painter分开的，复用的情况不多

from esui.

指定{string=}member不好吧，不如指定{HTMLElement=}element？

painters是在 类型声明 的时候用的，而HTML元素是在 实例运行 时候才出现的，因此这个不现实。

但我觉得member也不现实，我们不是所有内部dom都往control实例上挂的，而且，大多数应该是不挂的。

from esui.

rawValue和disabled就是普通painter搞不定的情况，就是缺少用painter（哪怕自定义的）也完全搞不定的时候，事实上是有的，就是场景不多见，正好Select控件也没用上。作文档时补上，这里主要是讨论……

那下面两种方式，选哪种？

var repaint = require('./controlHelper').createRepaint(...);
Select.prototype.repaint = function () {
    repaint();
    // process self repaint logic
};



Select.prototype.repaint = require('./controlHelper').createRepaint(..., {
    paint: function ( control ) {
        // process self repaint logic
    }
});

from esui.

确实是可以利用的，当然Select的源码里，updateValue只用在这一个地方（只是因为实现有点长，不写匿名函数了），一般来说paint方法没有啥复用价值，因为现有体系下，事实上所有的set最终都会转到repaint上，而repaint是一段一段通过painter分开的，复用的情况不多

既然是可复用的，我认为，多properties对应相同paint逻辑的事情，就不存在问题了

from esui.

但我觉得member也不现实，我们不是所有内部dom都往control实例上挂的，而且，大多数应该是不挂的。

通用的painter只能提供一种选择，认为他什么都能做就走偏了。对于非main的，又不挂在自己身上的，只好自己写了。另一种办法是让member接受一个函数，函数返回对应的HTMLElement，这样可以用class之类的找。

那下面两种方式，选哪种？

原来你说的是这个意思。参考createRepaint的实现，事实上最后那个paint的逻辑，接受的参数和其它的paint不同，普通paint接受(control, value)，而最后那个会接受changes，把前面的paint没处理掉的一起送过来。这种接口的不一致让我认为 第一种 更合适。

既然是可复用的，我认为，多properties对应相同paint逻辑的事情，就不存在问题了

会有一个问题，如果这么写：

[
    { name: 'x', paint: updateValue },
    { name: 'y', paint: updateValue }
]

那么当x和y都更新的时候，updateValue会执行两次，这通常是一种浪费，所以应该这么写：

[
    { name: ['x', 'y'], paint: updateValue }
]

但这又要求repaint把变化的东西合并起来，这个合并的逻辑在多数情况是不需要的，但因为有这需求又要每个属性都两边对比计算合并，感觉很浪费。

所以，我就没考虑这块的实现了

from esui.

原来你说的是这个意思。参考createRepaint的实现，事实上最后那个paint的逻辑，接受的参数和其它的paint不同，普通paint接受(control, value)，而最后那个会接受changes，把前面的paint没处理掉的一起送过来。这种接口的不一致让我认为 第一种 更合适。

我觉得第一种ok。不过如果是第二种，参数应该是control，没有changes。不需要changes，因为那是任何时候都要执行的repaint逻辑

from esui.

但这又要求repaint把变化的东西合并起来，这个合并的逻辑在多数情况是不需要的，但因为有这需求又要每个属性都两边对比计算合并，感觉很浪费。

这时候paint应该接受参数是(control, property1, property2......)，想用哪个用哪个。比如:

{
    name: ['rawValue', 'value'], 
    paint: function( control, rawValue, value ) {
        // just use rawValue here
    }
}

from esui.

通用的painter只能提供一种选择，认为他什么都能做就走偏了。

是的，但我觉得member参数实在是鸡肋...member是{HTMLElement}function()貌似开发时也很麻烦。我再想想...

from esui.

这时候paint应该接受参数是(control, property1, property2......)，想用哪个用哪个。

原来担心的问题是，name可以有多个的时候，没办法用简单的name: painter映射来查找到参数对应的处理函数，会变成O(n^2)的复杂度。后来又想了一下这问题可以解决不会影响复杂度，所以没问题就按这个来。

不过如果是第二种，参数应该是control，没有changes。不需要changes，因为那是任何时候都要执行的repaint逻辑

我倒认为并不一定是 任何时候都要执行 的逻辑，这个最后的painter我的理解是 剩下一堆挺麻烦而且相互关系比较混乱的属性统一处理 的作用，因此要给changes来标识 剩下哪些属性 。如果是 任何时候都要执行 的那部分，则忽略掉这个参数即可。

是的，但我觉得member参数实在是鸡肋...

我觉得还行，因为运行期动态产生的DOM元素，为了后续能够访问操作（比如用户鼠标点击时有些行为），一般就是2种做法：

1. 挂在this下当作某个属性，需要时this.xxx.style.display = 'none';这么写
2. 放在main下或给指定的id，到时候通过DOM遍历相关的函数，document.getElementById(this.id + '-xxx')这么写

member参数解决第1种情况，而让member变成function用来解决第2种情况，除此之外还会有哪些情况需要覆盖吗？

from esui.

我觉得还行，因为运行期动态产生的DOM元素，为了后续能够访问操作（比如用户鼠标点击时有些行为），一般就是2种做法：

我一般不放control实例上，而是随用随g
因为，免清除

from esui.

随用随g的情况下，member参数写成一个函数正好适用嘛

from esui.

我倒认为并不一定是 任何时候都要执行 的逻辑，这个最后的painter我的理解是 剩下一堆挺麻烦而且相互关系比较混乱的属性统一处理 的作用，因此要给changes来标识 剩下哪些属性 。如果是 任何时候都要执行 的那部分，则忽略掉这个参数即可。

给changes本身应该是没问题的，但是如果paint方法用了changes，那不包含在changes里的东西要从property里取，存在的从changes里取，再夹杂一些逻辑，就担心paint方法会逻辑混乱

from esui.

从现在的应用来看，changes只是用来标记 哪些属性变过 用的，真正取值还是从this.xxx来取的

其实我是不赞同有这个最后的painter的，看起来确实挺混乱的，还不如把repaint方法拆成一部分用生成的函数的调用，另一部分补上自己的代码

from esui.

随用随g的情况下，member参数写成一个函数正好适用嘛

member作为{HTMLElement}function() 肯定是能满足需求的，只是觉得易用性不太好

from esui.

原因就是我想不出更好的了，有更好的方案自然支持～

from esui.

从现在的应用来看，changes只是用来标记 哪些属性变过 用的，真正取值还是从this.xxx来取的

其实我是不赞同有这个最后的painter的，看起来确实挺混乱的，还不如把repaint方法拆成一部分用生成的函数的调用，另一部分补上自己的代码

en,那就是这样的模式了：

var repaint = require('./controlHelper').createRepaint(...);
Select.prototype.repaint = function () {
    repaint();
    // process self repaint logic
};

from esui.

原因就是我想不出更好的了，有更好的方案自然支持～

今天之内，再想不出来，就这样吧。。。

from esui.

en,那就是这样的模式了：

对的，我支持这种写法，特别的，创建的repaint是会返回 未处理的属性 的：

var generatedRepaint = helper.createRepaint( ... );
Xxx.prototype.repaint = function(changes) {
    changes = generatedRepaint.apply(this, arguments);
    // 这里是painter没处理掉的属性
    for (var i = 0; i < changes.length; i++) {
        var record = changes[i];
        if (record.name === 'xxx') {

        }
    }
};

from esui.

嗯，我也支持这样的写法

from esui.

html({string} name, {string} member, {function} generate)的member参数问题，突然有一点灵光：

member改名叫element，接受string|Function。Function行为如灰大描述，string则以此为id

from esui.

我仔细想了一下，这个是我受限于自己的**导致的问题。我比较习惯把东西都挂在当前实例下作为一个属性，自然就成了member指定属性名称。按ESUI的方案来，确实有用的部件应该有一个id，再通过这个id去访问，以避免过多的内存泄露的潜在风险，就这么发吧，周一我会处理完再提交

from esui.

关于member参数的问题已经在 3101b3b 中修复

from esui.

再总结一下现在的问题：

1. 需要提供多个属性对应同一个painter的方案
2. [new] 需要在helper.createRepaint中支持先调用父类的repaint方法

另：暂不计划支持所谓的“最后剩下的属性统一的painter”，这个去写repaint方法搞定就好

from esui.

在 c1d8509 中实现了属性的合并，name可以是一个数组，参考Select中把3个状态属性合并的写法

于是这个Issue也搞定了，可喜可贺

from esui.