报表一直是绝大多数企业项目应用中不可或缺的一部分，选择一款适中的报表软件，尤为显得至关重要。大型企业项目，BO或Biro之类的，占有量不少。对于中小型企业应用，则不得不考虑“性价比”了，而对于实施这些企业化应用的软件开发商，则不得不花很多精力来“衡量成本”。
中小型项目中，我接触过这么几款报表软件：开源的JasperReport，基于ReportServer的水晶报表，国产的润乾报表，国产的用友华表Cell。（以下所说，主要是基于web报表开发，毕竟目前B/S项目应用和客户需求很大）
相比较其他三款，Cell似乎不能算作“完整的报表软件”，至少缺少了应用中比较重要的“数据源采集”和“数据模型”这两块。因为缺少这两样关键的东西，让项目组使用Cell开发报表的时候，着实费力：笨拙的只能一格格的“代码式的灌数据”；聪明的另辟蹊径，封装一定量的脚本，以求缓解页面端的js工作量；再聪明点的，利用cell的readFromXML来灌输据，却发现“是一把断了刃的刀”，只能勉强可用。
即使Cell有如此大的缺陷和麻烦，但是，使用Cell开发的还是不少。估计这得益于cell的几个特点：Excel式的风格（虽然润乾也是电子表格方式的）；Web端展现的强大功能；开发虽然费劲，但是简单。
这几天因为要支持项目组，捣鼓了几天cell报表，着实体验了一番“欲罢不能”。为了减少项目组开人员操作js的工作量，从另外一个项目组吸收了一套“数据映射”的解决方案：利用cell的设计器设计cll报表样式，然后自定义了一套数据映射规则，描述当前报表的数据模型和数据映射关系；使用自定义的解析器经过解析和数据集灌输，生成可描述整个报表数据结果的xml文件。在页面端采用自封装的javascript脚本，对此xml进行解析和cell控件表表格的写入——这样就完成了一个前端cell报表的显示。
然而这种方式，效率却是很低，即使经过优化，针对简单的列表型报表显示，仅前端cell的js封装，显示１０００行的列表数据，都需要大约５秒多的时间。
客户对这个效率是很有成见的，不得已只好寻觅其他方式。搬出cell的帮助文档，终于翻出cell竟然支持xml数据导入，当然，这个xml格式是按照其自定义的。——当时感觉就像是“柳暗花明”，经过简单的测试，发现１００行的显示，只需要１秒多的时间——“又一村”啊。
然后，打击比我想象来的快：搜遍了cell的帮助文档，也没有详细介绍这个xml格式的schema文档，只有简单的一个例子供参考；给cell技术支持打电话，邮件沟通，得到的答复，让人心凉啊：没有schema介绍文档，包括后来开发人员查看了原码，也没有发现详细的注释，并且仅支持String和Number类型，而且这个xml仅仅只能用于灌输数据，不能执行一些“注入插入行，合并列”之类的操作，当然也不能设置显示样式。
后来······只能损失效率，换取样式了，毕竟客户最终不得不接受等待５秒的页面时间，至少等数据出来后，看得舒服点。
