dinghao

记录成长点滴

 

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

         从解析WordprocessingML开始,就想写一个基于xml的类库,我总觉得MSxml描述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。这次做的很彻底,完成了word90%以上标记的解析。

       有一天,我忽然想到这些解析一开始,就走错了方向。主要是被WarstarDev.Office2k7项目误导了。我是在用链表描述树结构,这才造成对xsd的一些元素如组,sequence,choice等很难用List描述出来。在word2007的解析中,我主要的时间都花在了如何简单准确的描述树结构,但不论怎么努力,结果都是差强人意。正确的做法应该是,解析的核心,仍然用树描述word,在暴露给客户的接口上,才需要基于这些树,做些façadeAsposeword好像就如此做的,我当时看他源码的时候,还对他用树描述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的脚本部分。新的脚本会基于MsAjax脚本库。我负责把服务器端迁移为Ajax控件(是否这点有必要?)。

如果想一起做,可以和我联系:msnhao_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

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

导航

统计

公告