十四冶建设集团技工学校网站,wp做网站,用来做微网站的,wordpress的小程序今天控件的开发有了很大进展#xff0c;写些东西。在开发之前#xff0c;我看了几个控件的源代码#xff0c;如Freetextbox,radtoolbr,abouteditor以及cuteeditor。今天凭会议总结一下他们的特点#xff0c;能记下来的都是他们很独特的地方。 首先是FreeTextbox 此控件是生…今天控件的开发有了很大进展写些东西。在开发之前我看了几个控件的源代码如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本身就包含许多不必要的文本如sddsss/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的资源文件也不是通过自己定义资源管理类来在用到资源时本地化。而是通过重写Textwriter的innerwriter和response的filter实现。细节上他用到了Idispose接口和using语句这样在缓冲去满或者dispose时自动实现资源的本地化。简直是绝了我一直没有想过能这样用dispose和这样实现资源。 其次对事件的处理这也是cuteeditor做的很好的地方它把所有的postbackdate和postbackevent封装到了两个隐藏域中这两个隐藏域是两个webcontrol他的值为post的数据和事件。这就使新增事件及其简便。只要加上postbackture就可以处理回发。 其次对脚本的管理他的脚本都是动态加载的因此不能调试。又是一个防止破解的招数。 通过httphandler他托管了*.js的加载。 再次配置文件的管理他在运行时会把几个配置文件加载到一个xmldoc中实现统一管理。Js也实现了类似功能。 还有Gizip以及缓存的管理方式都和一般人的不同感兴趣的自己去看源码。 类似的诡异实现还有很多。 我写的editor主要在下面几点做了改进 首先是子控件的管理上他的管理方式不算好。我把类似ForeColor的控件都抽出了基类。 其次我认为应该让客户更简单的自定义控件。因此在这点上也有改进。 再次net2.0已有的功能不再自己实现如Gizp在2.o已经有了Gizpstream。 我希望用Ma.js重写他的客户端脚本因此在服务器端尽量做些支持。 看了回复才知道还有个RadEditor看了他的代码和效果。发现它才是最好的。90分吧 其中界面满分20。cuteeditor和Radeditor都是20分。freetextbox10分 服务器端代码部分ce60freetextbox70radeditore70。满分80 转载于:https://www.cnblogs.com/neil-zhao/archive/2008/07/23/1250011.html
