InfoPath文件处理

以前一直想深入研究的JAVA & XSLT，终于有机会继续了，但没想到，研究的期限为一周，这周六必须出来一个demo，很刺激吧，嘻嘻——微软也真叼，它这.xsn的文件可以让他自己j++的类库来转成cab来解压来使用，就不让sun的java.util.zip来使用，shit！
先大概总结一下原理吧：

1、在InfoPath里创建一个表单，保存，就有一个后缀为“.xsn”的文件。
2、xsn文件其实是一个多文件的压缩文件，里面有几个xml文件和schema与xsl文件。
3、运用com.ms.util.cab.CabDecoder这类（微软的j++类）来把xsn文件解压，然后遍历里面的所有文件。
4、用xsl把xml文件解释成xhtml，把表单里的元素，如输入框，单选框等，作为字段元素存进数据库。
5、把xhtml的表单写进操作的jsp页里。

说难不难，说易也不易，java的TransFormer就可以很容易地把xml根据xsl的样式定义来生成html，但是现在关键是表单的元素都有约束条件的，而这些约束条件就定义在manifest.xsf文件里，需要提取里面的定义，然后把这些定义加到相应的表单元素中才进行保存，这点就有点难了。

今天继续研究时，发现了以下两个问题：
1、InfoPath里设计好的表单，用程序转换成html后，输入框不能编辑，但是在设计时设了非空的输入框，就可以编辑。
2、用了日期控件等非标准html标签，在转换成html后，就不能用了，这可能要进行转换。

输入框不能编辑的问题，今天一早回到公司，突然间灵机一动，原来已经实现了把用xsl文件渲染过的xml文件，并输出了一个DOM，那么，我再用xsl把这DOM再转一下，直接转成xhtml不就OK了吗，一试，果然成功了，至于那个日期控件，发现这日期控件的JS完全可以用开源的Calendar控件来实现，前几天就用过，直接搬过来就是了，加上汉化和修改文件路径，一个漂亮的日期选择控件就出来了。

跟着，就遇到了InfoPath自己带的控件转换问题，InfoPath里照顾到了复杂表单（表单里含有多行表格的填写），而要把这些重复表什么的控件转换成什么呢？真的不晓得，看InfoPath的SDK，发现要完全在浏览器中把其所有表现方式复制，必须能够使用InfoPath里的对象模型，也就是其特有的对象，哎，这真的无语，进度不能拖，要不然，把InfoPath拆了。
明天，必须实现数据的填写提交保存，然后查询，目前的想法是，先读取创建好的html，然后填写，把填写的数据，以xml的形式（文档结构和生成html的xml一样）存放到数据库，在读取表单时，用这个xml文件+xsl再转换成xhtml的格式输出。至于表单数据的修改，等实现了第一步的数据保存再想办法。

今天写数据提取时，又发现了“恶心”的东西，ms怎么要这么做呢！
用InfoPath的模板设计的表单，其schema是一个非常复杂的文档，表单的元素并非独立的，基本上每个元素，都被一个父元素包含，这不是关键，关键是它把很多不需要的元素也加到了schema里，哎！不知道怎么办。
还有一个就是转换后的html文档里表单的控件的名称，是在转换时自动生成的，但是在schema里，这些元素的name又是用户自己定义的，哎，怎么对应上啊！
天啊！救命啊！
今天收到了“jinForm”创始人David的来信，他用XFORM实现转换，但也没办法很好的处理数据与表现。

又过了一天，今天已经星期六了，不现在已经是星期天0:39了，经过2个半小时的google，终于让我把那个chiba-web运行起来了，哎，开源的东西，真的是让人爱，有让人恨，好端端的一个包，竟然拆开几个，shit again，他妈的，明天就要把这XFORM搞定，哎，又要加班了。不管了，明天拼了，不出来，就不睡。

今天进度完全不行，在公司呆了一天，弄来弄去，还是无法把InfoPath的表单完全转换成XFORM，最大的问题是出来的xhtml文件，在用chiaba-web转换后，在客户端（浏览器）展现时，样式表（CSS）的内容没了，这是chiba-web的“杰作”，也和转 XFORM时屏蔽了部分样式表的加载有关，今晚想在家里继续研究的，谁知道家里的eclipse插件不够，竟然不能把jboss4设置成默认的Server，fuck！目前，只能够再深入地看看XFORM和XSL的关系了。

转载于:https://www.cnblogs.com/TV9/archive/2006/09/12/502450.html