感谢外加这几天的使用波折,再加几个小建议和小疑惑

google-code-export / xheditor

Automatically exported from code.google.com/p/xheditor

GNU Lesser General Public License v3.0

1 stars 1 forks source link

    这几天在做一个网站,因为会写属于自己的上传功能,而且有时候会把数据写入论
坛,因此编辑器本身主要的要求是精简、比较好的支持word粘贴
、支持ubb,分析了不下
几十种编辑器后选定xheditor.
    结果使用的时候,发现xheditor在firefox和ie8上表现良好,但到了ie6和ie7就死
活不显示.原因一直找不到.同样的操作方法,安装tinymce,一点问
题都没有.于是我犹
豫了很长时间,还是转到了tinymce.昨天把所有的开发完成后，��
�然想到忘记看
tinymce的ubb功能了，然后试了一下。发现其的确有可视化ubb编�
��功能，但是我把
word文档里的文字粘贴进去的时候，他还是转成了html，他的ubb
仅仅是支持ubb显
示，如果客户端的人使用html，他还是支持的，这样带来的安�
��隐患肯定是存在的。
我挣扎啊，咬牙一狠心，决定换。于是连夜再度把编辑器都��
�究了一番，总结了如下
经验与成果，与大家分享：
1、如果是交互式的网站，编辑器我认为还是使用ubb的方式比�
��好，主要是能解决很
多安全的隐患，毕竟做的不是新浪这种大投资项目，如果使��
�html编辑器，后面的安
全问题可能会很多。

2、同样的编辑器，转换word的能力是不同的，对于各种段落字
体控制等转换能力也是
不同的。我测试过好多编辑器，这里只列举小型轻量级的编��
�器结果，国外2个，国内
2个：
    把word里的一个1000多中文字的通知，其中包含超链接等粘贴进编辑器（如果链
接、字型、字体等变化多的话，测试结果会大相径庭，我这��
�的例子只能作为参
考。），如果要保持原来的风貌，一个1000字的文章可能会被�
��同的编辑器转换成
5000~30000字符。xheditor是13000多，tinymce是35000多，kindeditor是28000
多，WYMEditor是5700多。
    如果是一个8*8的表格，里面什么内容都不放，转换出来的字符数量差距是非常大
的的，xheditor是19000字左右，tinymce是2700多，kindeditor是19000
多，WYMeditor3500。这个测试国内2个编辑器可以说溃败。
    如果是一个8*8的表格，里面放39个中文字。xheditor：19508
字，tinmce：2682，kindeditor：21512字，XYMeidtor3700字。
    这么看来对于表格的处理，我们的编辑器还需要加强，差距很明显，有的竟然相
差8倍，而对于文字、链接等转换，我们属于中流。
    附：如果使用XHEditor的ubb编辑器，那么那篇通知为6000多字，不带字表格2500
字，带39中文字的表格为2391字。这么看的话，ubb对于简少字��
�，减轻数据库压力是
很有好处的！
    话外音：如果使用html编辑器，我真的很喜欢XYMeditor，他转换出来的代码全部
都是标准的css格式，太漂亮了，真是爱不释手！可惜他的编��
�方式有些非主流，本身
也不是很成熟，想想如果给普通用户用，他们才不管代码怎��
�样，主要是方便。

3、编辑器的二次开发，拿来就用的编辑器，二次开发比较简�
��的我用下来还是觉得
ewebeditor最好，比较傻瓜化，不过这可是重量级的，只能管理�
��后台用用。其他的
编辑器用了一下，其实都差不多，xheditor算代码比较少的了。

============================================================
建议：
1、目前路径支持不好。就是我开头写的为什么死活ie6 
ie7不支持，我今天早上灵光
突现，比较了3种浏览器后，想到自己写在head写了<base
href="http://xxx.xxx.com" 
/>，而调用js的时候，使用了路径类似src="plugin
/xeditor/jquery/jquery-1.3.2.min.js"，后来把路径改成src="http://xxx.xxx.
com
/plugin/xeditor/jquery/jquery-1.3.2.min.js"，一切就都好了。这个问题�
��其他几
个编辑上暂时没有发现，可见xheditor对路径的支持需要改进。
2、js代码的转换，我也说不清楚，忘了。反正就是我在二次��
�发的时候，发现有些地
方很不顺手，容易出错，其他编辑器没有这些问题。
3、对于ubb的转换，如果粘贴进一个表格,发布成功后再重新编
辑，这个表格边框就看
不到 
，隐形了。。。。如果同样的代码放到discuz编辑器里就又能��
�到表格了。

============================================================
问题：
如果使用ubb，前端显示的时候需要转一次，不知道对于服务��
�压力会不会增加？

Original issue reported on code.google.com by Spik...@gmail.com on 17 Oct 2009 at 2:54

感谢您提供这么多的意见，关于这些问题作如下回答： 1，我研究过WYMeditor这个编辑器，这个编辑器实际上是非常不� ��善，所以拿来做比较基本上没意义。这个说法并不是故意损他们，只是这个编辑器真的是�� 方面都不完善，包括各浏览器的兼容性问题，除了CSS编辑方面做的有点意思，其它功能真的拿�� 出手。 2，WORD表格之所以比不上国外的转换，是因为国外的两个编辑器是以完全清除style为基础的，这样的后果就是有些WORD的样式就会损失比较严重，比如字体� ��色什么的。在xheditor开发的过程中，经过比较之后才决定将样式保留下来，但是要尽可能�� 缩减样式体积，而且要尽量完美的还原WORD中的各种样式效果。关于这个问题，我觉得可以设置� ��个选项让网站开发者自己决定是否开启WORD样式清理功能，如果仅仅只是希望从WORD那边复制一个文字和框架，那么样式的确是可以省略的。 3，关于路径的问题，我测试下来，发现这个问题是IE6和IE7的B UG。按道理来讲，既然页头上设置了base，那么页面里任何非绝对地址应该都以这个地址为基� ��。直接HTML输出的内容是正常显示的，但是如果用javascript输出内容，比如图片什么的，就被� ��成相对地址来定位了，这显然是浏览器的BUG，这个问题除了IE6,IE7，其它所有浏览器都没有� ��个问题。个人认为，这个问题既然是IE早期版本的BUG，并且利用base来对页面内容进行定位�� 应用相对较少，个人认为这个问题可以忽视，而且真要解决起来，估计会比较麻烦。之所以�� 它编辑器没出现这种问题，极有可能他们样式表的引用不是通过javascript来输出的。 4，JS代码的转换不知道是什么意思？ 5，关于ubb的表格边框，这个编码层实际上都是一样的，之所� ��discuz编辑器会显示表格，实际上是他们默认强制显示表格边框了，因为论坛中表格是用来�� 放数据的，而表格的边框是调用论坛默认样式的。我们这个编辑器的ubb表格代码也参考了目前�� 有主流论坛的代码，因此表格的代码中也并不存在边框这个属性，所以转换ubb再转换回来，自�� 就会出现不显示边框的问题。这个问题我觉得您也可以参考discuz论坛，在最终输出页强制�� 内容中的表格进行样式显示，如果您希望在编辑时也进行强制表格边框显示，那您可以修改xh editor模板中的iframe.css 6，关于ubb转换的压力问题，我觉得您可以在显示页面上实现� ��个缓存功能，不要每次用户访问都去访问数据库来转换ubb，这样不管有没有用ubb，都是非常�� 合理的。

非常感谢啊。回了这么多内容。恩，我今天仔细研究了一下，发现很多还是因为自己无知提�� 的问题。关于wymeditor，他的css的确我真的太喜欢了，其他地方问题超�� 。。。路径问题原来是bug。。。。万恶的ie6啊。感谢分享经验啊。 ubb的表格边框，我今天研究了一下，正如你所说的那样，不�� 于编辑器管的事情了。还是要网页程序比较人性才行。我现在前端显示使用XHEditor的ubb.js中的ubb2html，仿照discuz扩展� ��一下图片环绕这个功能（编辑器没有这个功能，如果用户懂的话，前端可以正常显�� ，嘿嘿）。我用js来渲染页面，我想有几个好处，一来不用再让服务器把页面转成html了，把这� ��事情交给用户客户端去做；二是 ubb代码量少，减少带宽和数据传输量；三是如果页面出错，�� 看到的ubb还是能看懂的，不像 html。。。。不知道我这个思路对不对。我现在做的这个东西不是论坛，是类似多用户的cms用户中心�� 总是担心被人挂马什么的，所以最后还是决定使用ubb，比较好管理。再次谢谢

google-code-export / xheditor

感谢外加这几天的使用波折,再加几个小建议和小疑惑 #75