讨论一下,Ext里哪个组件设计的最不好

最近在一直做Ext的研究 代码结构方面的.
并且做一些修改和扩展.
多少也研究了不少他的组件.

EXT有多强大多NB就不用我多说了 但是任何好的事物也都有不好的方面

大家来讨论讨论呢 哪个ext的组件设计的不最不好吧

我先说说我的观点:

我觉得最不好的就是 他的树.
首先 设计的不够灵活(想灵活也行 但是需要开发人员做很多事情)
其次 严重违背了ext自己的一个设计理念: 数据与展现分离.

Tree,Node,TreePanel, TreeNode,AsyncTreeNode,TreeNodeUI, TreeLoader....
彼此之间的关系混乱复杂, 有很多错误的关系(我认为错误 并不一定真的错误)


大家觉得还有哪些组件设计的不够好呢???


下面附上一张我对ext tree的分析图 还有我的一个重构目标

评论

22 楼 liweisex 2008-12-18  

发表评论的都是牛人。发个跟屁贴表示我存在过、关注过、路过。

21 楼 walkman 2008-12-17  

很多涉及 ajax 请求的组件不能自定义请求参数，比如 TreeLoader 的 requestData 方法，我要在请求的时候添加一个 header，就只有重写该类的这个方法，否则必须继承该类再重写这个方法，很郁闷

这个情况在其他组件中也经常遇到

20 楼 nihongye 2008-10-06  

hqs998 写道

EXT用的不多，就几个月前为一项目做了些模块
1、property grid 的确很吐血，得频繁的看源代码来了解其工作原理和属性等等，并且放入数据的格式还分为source和store，store比较灵活些，能直接把后台的传来的JSON数据放进去，但是做项目时好像是不好刷新中间的数据，source就太死了，只能把数据硬写进去

2、EXT的布局也比较烦人，感觉比swing还难调试。。好像现在出了类似DELPHI一样的拖拉组件能方便一些？

一些细节的东西，文档和例子没交代清楚，需要自己看代码挖掘，了解清楚后，布局很好控制

19 楼 walkman 2008-10-06  

本人窃以为，ext那些成型的组件都是给懒人用的，是告诉你我可以做成这样的效果，我可以牛逼到这个程度。但是一个成型的产品你还想怎么修改怎么扩展？？
应用它的 Observable 类，从 Component 到 Container 一路继承下来开发自己的组件才是硬道理，否则你的网站也只是成千上万个使用 ext 的站点中风格雷同的一个:(

18 楼 hqs998 2008-09-26  

EXT用的不多，就几个月前为一项目做了些模块
1、property grid 的确很吐血，得频繁的看源代码来了解其工作原理和属性等等，并且放入数据的格式还分为source和store，store比较灵活些，能直接把后台的传来的JSON数据放进去，但是做项目时好像是不好刷新中间的数据，source就太死了，只能把数据硬写进去

2、EXT的布局也比较烦人，感觉比swing还难调试。。好像现在出了类似DELPHI一样的拖拉组件能方便一些？

17 楼 bailm 2008-09-22  

呵呵，接触这个东西很久了，但是没研究过底层的东西。
要说不好用的，有个property grid,我一看到就惊讶，一用就想自杀

16 楼 yongtree 2008-09-19  

我认为form做的不是非常的灵活，写的太死了。
特别是checkbox，radio，写起来蛮难受的，而且和后台交互也不是非常的直接。

15 楼 rikugun 2008-09-18  

Maniacdragon 写道

htmleditor，功能太少了。

其实你可以用fckeditor的,mice也不错.都可以嵌入到里头

14 楼 Maniacdragon 2008-09-17  

htmleditor，功能太少了。

13 楼 jianfeng008cn 2008-09-13  

目前而言我还是喜欢ext这种务实的做法

12 楼 fins 2008-09-11  

EXT 和 dojo走的是完全不同的两条路

ext就是要让大家忘掉HTML

ext本身更像是一种 语言

ext之于js
就好像 swing之于java

11 楼 radar 2008-09-11  

jianfeng008cn 写道

radar 写道

不好意思跑题了。
一直认为既然你选择了EXT，去扩展它不是个明智的选择。

一直认为EXT 的Cache 是影响性能一个主要原因。

Class A={
   this.dom
   this.Element
等等
}

缓存了很多对象。

selector 不要只针对Dom了，应该是对象。

不明白，不要针对dom针对对象是什么意思？针对哪个对象？

<img></img>
在javascript中是个dom对象吧。
那你自己写的树假设是 <tree></tree>。 也可以看作”dom对象“
至于node什么的。
<tree><node></node></tree>
对html来说是个标签，对javascript来说是个dom对象。

至少dojo是从这个角度来扩展 “组件” 的。我想也是未来的趋势，可能有些关键技术javascript/html等支持的不是很好，dojo才有n多人讲的诟病吧。

但dojo对html5的贡献还是有的。

EXT太着重javascript了，忽略了html标准规范。

10 楼 jianfeng008cn 2008-09-11  

radar 写道

不好意思跑题了。
一直认为既然你选择了EXT，去扩展它不是个明智的选择。

一直认为EXT 的Cache 是影响性能一个主要原因。

Class A={
   this.dom
   this.Element
等等
}

缓存了很多对象。

selector 不要只针对Dom了，应该是对象。

不明白，不要针对dom针对对象是什么意思？针对哪个对象？

9 楼 radar 2008-09-10  

再扩展一下。
大家回忆下dojo的dojoType.或者html5
我们为什么自己编写组件呢，因为html提供的标准组件不够用。
那我们写的组件和html提供的标准组件 有什么关系呢？

我希望是这样的
document.getElementById(id);
不仅可以获取 html提供的标准组件。
也可以获取扩展的组件。例如 Ext提供的组件。

8 楼 radar 2008-09-10  

不好意思跑题了。
一直认为既然你选择了EXT，去扩展它不是个明智的选择。

一直认为EXT 的Cache 是影响性能一个主要原因。

Class A={
   this.dom
   this.Element
等等
}

缓存了很多对象。

selector 不要只针对Dom了，应该是对象。

7 楼 jianfeng008cn 2008-09-10  

nihongye 写道

fins 写道

最近在一直做Ext的研究 代码结构方面的.
并且做一些修改和扩展.
多少也研究了不少他的组件.

EXT有多强大多NB就不用我多说了 但是任何好的事物也都有不好的方面

大家来讨论讨论呢 哪个ext的组件设计的不最不好吧

我先说说我的观点:

我觉得最不好的就是 他的树.
首先 设计的不够灵活(想灵活也行 但是需要开发人员做很多事情)
其次 严重违背了ext自己的一个设计理念: 数据与展现分离.

Tree,Node,TreePanel, TreeNode,AsyncTreeNode,TreeNodeUI, TreeLoader....
彼此之间的关系混乱复杂, 有很多错误的关系(我认为错误 并不一定真的错误)


大家觉得还有哪些组件设计的不够好呢???

  也做了些树的扩展，不过自己做的很不好，估计我把代码贴出来，会把很多人搞的吐血。我一直主观上认为TreeNode不应该继承Node，这点让我很排斥，fins的这个讨论让我提起看Ext代码的兴趣，得出不同的结论。

  第一:data.Node和tree.TreeNode从包名的分解看，data是管数据的，tree是与tree有关的，两个包是单向的关系；而从TreeNode的代码看，包含了节点的展现行为（注意，这里是行为，不是样子，样子由TreeNodeUI管理）控制。从这两点看，TreeNode的设计是合理的。

  第二：TreeLoader，构造出来的是TreeNode，
数据加载上：doPreLoad模式支持已准备数据的;动态request上，支持json数据，需要支持xml，可以通过覆写processResponse来达到，缺乏解析xml的支持;创建的节点上，类型可指定也可以覆写方法来达到目的。
总体感觉划分清晰，也灵活吖。

我也觉得ext这样的结构是合理的，只要treenode继承data.node有点不能接受

6 楼 nihongye 2008-09-06  

fins 写道

toolbar 确实也够郁闷的 和ext其他地方的组件机制不一样

================

主楼补充了一张图 是我对树组件的一个简单分析 和我的重构目标

恩，Toolbar是个异类

5 楼 nihongye 2008-09-06  

fins 写道

最近在一直做Ext的研究 代码结构方面的.
并且做一些修改和扩展.
多少也研究了不少他的组件.

EXT有多强大多NB就不用我多说了 但是任何好的事物也都有不好的方面

大家来讨论讨论呢 哪个ext的组件设计的不最不好吧

我先说说我的观点:

我觉得最不好的就是 他的树.
首先 设计的不够灵活(想灵活也行 但是需要开发人员做很多事情)
其次 严重违背了ext自己的一个设计理念: 数据与展现分离.

Tree,Node,TreePanel, TreeNode,AsyncTreeNode,TreeNodeUI, TreeLoader....
彼此之间的关系混乱复杂, 有很多错误的关系(我认为错误 并不一定真的错误)


大家觉得还有哪些组件设计的不够好呢???

  也做了些树的扩展，不过自己做的很不好，估计我把代码贴出来，会把很多人搞的吐血。我一直主观上认为TreeNode不应该继承Node，这点让我很排斥，fins的这个讨论让我提起看Ext代码的兴趣，得出不同的结论。

  第一:data.Node和tree.TreeNode从包名的分解看，data是管数据的，tree是与tree有关的，两个包是单向的关系；而从TreeNode的代码看，包含了节点的展现行为（注意，这里是行为，不是样子，样子由TreeNodeUI管理）控制。从这两点看，TreeNode的设计是合理的。

  第二：TreeLoader，构造出来的是TreeNode，
数据加载上：doPreLoad模式支持已准备数据的;动态request上，支持json数据，需要支持xml，可以通过覆写processResponse来达到，缺乏解析xml的支持;创建的节点上，类型可指定也可以覆写方法来达到目的。
总体感觉划分清晰，也灵活吖。

4 楼 kebo 2008-09-05  

tree:目前不支持xml，而且不好扩展，数据格式不可以自定义解析，比如text属性
PagingToolBar:分页参数limit，带查询条件的分页，分页的时候要把参数带着的话，得费一番周折。麻烦死了

3 楼 fins 2008-09-05  

toolbar 确实也够郁闷的 和ext其他地方的组件机制不一样

================

主楼补充了一张图 是我对树组件的一个简单分析 和我的重构目标