dinghao

记录成长点滴

 

从控件开发的角度看几个editor控件,Freetextbox,radtoolbar,abouteditor,cuteeditor

  今天控件的开发有了很大进展,写些东西。在开发之前,我看了几个控件的源代码,如Freetextbox,radtoolbr,abouteditor以及cuteeditor。今天凭会议总结一下他们的特点,能记下来的都是他们很独特的地方。

首先是FreeTextbox

此控件是生成的控件(相对于复合控件),不论是toolbar还是toolbaritem,都不是以子控件的形式存在,因此有更好的性能。这种方式的缺点是,不能很好的利用现有的Asp控件,降低了用户自定义控件的方便性。如,我想在toolbari上加上combox,必须自己实现。

视图状态,视图状态的管理是令人头疼的问题,弄不好就会加大视图状态的大小。从Freetextbox对视图状态的实现来看,它的实现中规中矩,完全符合ms推荐的实现方式。但是,是否每个toolbaritem都有必要实行视图状态?其实从Freetextbox的实现分析,大部分的实现是不必要的,因为他们都不会改变。如果把这些实现剔除,Freetextbox的代码会简单很多。

子控件的实现方式,此控件不存在子控件,toolbaritem被定义为实现了IstateMananger的类,每个Item都是一个类,如BoldItalic等。

总之,这个控件的服务器段代码,十分符合MS推荐的控件实现方式,它的内部实现,类似于ASP的服务器控件实现。也符合常人的思路,代码比较容易理解。结构也不错可以给80分。

其次,Radtoolbar

此控件用的是复合控件。每个toolbaritem都被实现为子控件,并且暴露给客户。从用法来看比较像asp的一些复合控件,即子控件要在aspx中声明。但这种方式对客户来说,用起来很不方便,因为要写许多声明代码。

视图状态,此控件对视图状态的管理,可以说坏到了极点。它竟然通过把控件的属性序列化为xml,然后把xml作为视图状态。这就造成,任何一个细微的改变,都会把视图状态项记为dirty,造成整个xml序列被序列化的客户端。再者xml本身就包含许多不必要的文本,如<sdds>ss</sdds>。可以看到元素名称是很浪费空间的。这就造成此控件的视图状态,会比标准的asp实现大十倍左右。

子控件的实现方式,子控件是通过序列化的方式从配置文件读取。子控件没有细分,如没有类似于BoldItalic的项。只被粗略分成了Toolbarbuttontoolbarseprator等。

总之,这个控件实现没有细看,因为不论从哪方面来说,它都算不上优秀。50分。

AboutEditor

这个控件的实现类似于Freetextbox,也不是复合控件。

视图状态,他没有为toolbarItem实现视图状态,因为这几乎没必要。

子控件,他同样不存在子控件,与freetextbox的不同在于,他没有细化每个toolbaritem

总之,此控件和freetextbox很相似,我没有细看。

最后是Cuteeditor

看了他的demo,很震撼,应该是所有editor中效果最好的。

Cuteeditor用复合控件实现,缺点是增加了控件树的开销,效率没有生成控件高。优点就是,客户实现自定义功能较方便。

由于用子控件,大部分视图状态都可以交给webcontrol管理。

他对子控件的实现我认为不算太好,简单的控件都从一个基类派生,这点如果还算不上缺点,那么他对Forecolor等的实现方式,确实不算好。

总之cuteeditor是功能里面最强大的。但是他的实现,很难让人理解。不像Freetextbox,有中规中矩的实现。60分。

 

看了几个实现,可以说实现方式五花八门,除去视图状态不谈,只要把htmlrender到客户端,控件就算完成了。这就造成实现控件的方式很多。应该怎么写,确实值得思考。

Freetexbox,占去了大概一周的时间,这段时间我仔细看了他最新版本,以及更早版本的代码,它的实现和符合正常人的思路,很容易理解。对他的实现了解太多,以至于不想参考他的实现了。主要是怕写完代码和他特别像。从结构上来看,它的缺点我认为主要在于,把子控件的生成操作,都延迟到了父控件,造成父控件逻辑负杂。我最初的想法是,在Init的时候,构造一个xmldocument,然后每个子控件通过xml的方式,增加xmldoc的节点,最后再返回xmldoc给父控件。

Cuteeditor用了两三天的时间,他的代码很乱,几乎不符合常人的思路。尤其他为了防止破解,故意调整了几个类的顺序,如Editor,嵌套了四五层的内部类,让人看起来很头痛。从他的html看,也不像其他控件一样,能得到许多有用信息。

由于他的效果最好,并且我看了好久都没有头绪,觉定从他下手,写一个类似的editor

其他的几个控件,和这两个相比都差很远,忽略。

经过近一个月的努力,控件开发终于过半,对cuteeditor的研究也更深入了,觉得他的许多实现确实很诡异,也让人眼前一亮。增加到80分。

Cuteeditor特点

首先,它对资源文件的处理方式来看,他没有采用.net的资源文件,也不是通过自己定义资源管理类来在用到资源时本地化。而是通过重写Textwriterinnerwriterresponsefilter实现。细节上,他用到了Idispose接口和using语句,这样在缓冲去满,或者dispose时,自动实现资源的本地化。简直是绝了,我一直没有想过能这样用dispose和这样实现资源。

其次,对事件的处理,这也是cuteeditor做的很好的地方,它把所有的postbackdatepostbackevent,封装到了两个隐藏域中,这两个隐藏域是两个webcontrol,他的值为post的数据和事件。这就使新增事件及其简便。只要加上postback=ture,就可以处理回发。

其次,对脚本的管理,他的脚本都是动态加载的,因此不能调试。又是一个防止破解的招数。

通过httphandler,他托管了*.js的加载。

再次,配置文件的管理,他在运行时,会把几个配置文件加载到一个xmldoc中,实现统一管理。Js也实现了类似功能。

还有,Gizip,以及缓存的管理方式,都和一般人的不同,感兴趣的自己去看源码。

类似的诡异实现还有很多。

我写的editor,主要在下面几点做了改进:

首先是,子控件的管理上,他的管理方式不算好。我把类似ForeColor的控件都抽出了基类。

其次,我认为应该让客户更简单的自定义控件。因此在这点上也有改进。

再次,net2.0已有的功能不再自己实现,如Gizp,在2.o已经有了Gizpstream

我希望用Ma.js重写他的客户端脚本,因此在服务器端尽量做些支持。

看了回复才知道还有个RadEditor,看了他的代码和效果。发现它才是最好的。90分吧
其中,界面满分20。cuteeditor和Radeditor都是20分。freetextbox10分
服务器端代码部分,ce60,freetextbox70,radeditore70。满分80
 

posted on 2007-09-06 23:49 思无邪 阅读(...) 评论(...) 编辑 收藏

导航

统计

公告