想做一个关于word解析和HtmlEditor的项目，希望有人加入

         从解析WordprocessingML开始，就想写一个基于xml的类库，我总觉得MS以xml描述Office文档，是一个机会。但是这个类库，应用范围比较窄，我对他的前途有些怀疑。我希望，这个类库配合一个基于html的编辑器，这个编辑器和流行的一些Editor的不同之处是，它能更好的和word格式之间互操作。如，对html的修改可以反映到word上。

      编辑器项目

       由于我对Javascript了解很少，编辑器只能想想，并没有能力去实现。后来又有机会学习了Ajax，系统的学习了一次Javascript。这时我觉得可以有实力去做这个编辑器了。

       不过，我对自己的Js缺乏信心，想到一个捷径，利用一个现有Editor的脚本文件。我只重写服务器端的代码，这样一来可以省去Js的麻烦，二来也可以在第一个版本就尽可能的做到比较实用的效果。这个版本出来后，可以再考虑，自己写脚本，我希望这个脚本是基于Ajax.net的脚本库。

      Word解析项目

       最初解析word是因为公司一个项目的需要，这个项目需要把word转换成html，编辑html后能把修改再写入到word。以及把一些自定以表记转换为html标记。

       当时听说了wordprocessingMl，就以他为基础解析，。为了简便，当时只解析了部分word标记。

       由于当时的解析是基于word2003，第一次做，对那次解析也不满意。我有时间的时候，开始基于word2007解析word。这次做的很彻底，完成了word中90%以上标记的解析。

       有一天，我忽然想到这些解析一开始，就走错了方向。主要是被WarstarDev.Office2k7项目误导了。我是在用链表描述树结构，这才造成对xsd的一些元素如组，sequence,choice等很难用List描述出来。在word2007的解析中，我主要的时间都花在了如何简单准确的描述树结构，但不论怎么努力，结果都是差强人意。正确的做法应该是，解析的核心，仍然用树描述word，在暴露给客户的接口上，才需要基于这些树，做些façade。Asposeword好像就如此做的，我当时看他源码的时候，还对他用树描述word有些嘲讽，其实这才是正确的做法。

       这些解析的优点是，可以脱离word来操作word文件。至少从效率上，比调用vba或者vstc（？）快很多，因为它没有必要调用word内核。

目前的一些进展：

Word解析方面：

这是转换的一些截图，版本是最初项目用到的2003版本。

包含标记的word

对应的html，把word重的textbox标记转换成了文本框，保留标记替换成了文本。（注，由于忘记考xsd，这些标记显示不出来）

包含表格的word

 

对应的html

Editor的进展：

这个刚开始做，不过到今天总算完成了服务器端的大部分工作，如果有时间，再过两周就会有一个实用的版本出来。

截图。

后续的想法：

Word的解析部分，整个从新开始。目前先不做这部分，不过因为又以前的基础，这部分比较有把握完成。

Editor部分，控件开发和Js以前都没有做过，一直对他没有底。不过，由于现在服务器端以经完成了一半多，也算稍微有把握了。

在这个项目的目标是，Editor方面，首先赶上Cuteeditor，word方面，赶上asposeword。然后再在Editor上加操作word的功能。

整体的结构图，比较粗略

 

这个图不详细，依赖都应该是关联，由于这个软件表示有方向的关联比较麻烦，我一般都用依赖了。

写这篇文章有两目的：

一是，不想一个人做了，凭我一个人的力量，恐怕到明年这个时候才能完成。

二是，提醒自己，不要放弃，把这个项目完成。

目前，想找个熟悉JS的，我们可以一起完成Editor的脚本部分。新的脚本会基于Ms的Ajax脚本库。我负责把服务器端迁移为Ajax控件（是否这点有必要？）。

如果想一起做，可以和我联系：msn：hao_ding@eyou.com,联系之前首先考虑下自己Js的水平，因为我js不行，想找个高手。

附录一：
Hibernate成功的原因　　
　　1、飞快的版本发布
　　
　　保持活跃的开发速度，经常进行版本发布，甚至几天 之内就从前一个版本开发到下一个版本。这样是保证软件远离Bug的最好的办法，也可以让用户感到很放心，确信Hibernate的开发十分活跃，另外这样做也有一大好处，就是可以发现哪些功能是用户真正需要的。
　　
　　2、回归测试
　　
　　我想现在整个Java社区一定都很重视自动回归测试。如果软件的功能和设计有比较大的修改，那么一个综合性的test suite对于软件可维护性和稳定性来说实在是太重要了。我们应该有这样的意识：如果对软件的一个新功能没有进行回归测试，我们根本就不该去做它。
　　
　　3、把一个功能做到最好
　　
　　要么不做，要做，就一定做到最好。那些我们做不到最好的功能，我们根本不去做，扔给其他软件去做吧。
　　
　　4、避免过度设计
　　
　 　浪费大量的时间和精力进行软件功能的抽象和扩充软件的灵活性，还不如多花点时间来解决你的用户面临的实际问题呢！简单一点，软件最重要是运行起来，不要 尝试去解决你的用户根本不关心的问题。就算你的软件设计的不够优雅也没有关系，反正还是initial阶段。以后还可以再refactor，你应该关注的 问题是及时的把有用的功能给做出来。

　　
　　5、集权
　　
　　在你需要由民主投票来下决定之前，至少你已 经把软件轮廓做好了。软件开发需要由一两个开明的人来领导，这样可以保证软件开发的连贯性而不至于产生太大的分歧，可以保证开发团队集中火力把要实现的功 能做到最好。我觉得，OSS软件最大的风险就是意见不统一，摊子铺的太大，结果最后搞的什么都没有做好。
　　
　　（译者按：非常赞同，凡是成功的OSS软件，都是在某个人已经把软件做好了之后，发布出来，然后由大家往里面添加功能的，并且在这个人的领导下不断进步。缺乏此人的OSS软件都不算很成功，比如Mozilla）
　　
　　6、文档
　　
　　没有什么比文档更重要的了。如果你的用户不知道你的软件有这么一个功能，就等于没有这个功能，干脆把它去掉得了，省得给源代码增加复杂度。
　　
　　7、避免标准化
　　
　　好的标准可以带来软件的互用性和可移植性，坏的标准能够窒息软件创新。最好的软件是在不断的尝试，不断的出错，不断的经验积累的过程中产生的。事实上的标准往往更加贴近用户需求。
　　
　　8、10分钟之内把Hibernate跑起来

　　
　　潜在的Hibernate的用户在他们下载了Hibernate，第一次使用的时候根本就不可能花半个小时那么多时间来安装、配置和 troubleshooting，他们早就丧失了对Hibernate的兴趣了。
　　
　　我们的口号就是新用户（假设有足够的JDBC知识）5分钟之内把 Hibernate的Demo跑起来，而他们能够在1个小时之内写出“Hello World”式的最简单的Hibernate程序并且正常运行。
　　
　　9、开发人员的责任感
　　
　　用户总是不可避免的碰到问题，开发团队有责任有义务提供帮助。用户让我们知道了文档的漏洞，用户让我们知道了测试用例的小bug。此外，没有用户来用我们的Hibernate，我们还开发它做什么，不是浪费时间吗！
　　
　 　有个关于bug的笑话：用户根本不介意发现新功能的bug（译者按：Windows的用户好像都是如此），只要你能迅速的改掉bug。“责任感”意味着 bug修复应该在1周之内。从收到bug报告到bug修复代码提交到CVS上要做到平均在24小时左右，这才是一个理想的目标。
　　
　　10、易用的、可更新的wiki网页
附录二：
目前两个商业项目：
cuteeditor，http://cutesoft.net/
他的价格：从129到7999
http://cutesoft.net/ASP.NET+WYSIWYG+Editor/Purchase+CuteEditor+for+.NET/default.aspx
aspose word，http://www.aspose.com/Products/Aspose.Word/
价格：从899到10788
http://www.aspose.com/Purchase/Aspose.Words/Default.aspx