看了一下BIRT。 想起在前一家公司使用Oracle BAM， 当时就我一个人搞BAM，从零开始，把东西学的差不多后发现Oracle BAM要做起应用来极其崩溃，几乎要把我折磨死。Bug一堆不说，功能设计也相当鸡肋。虽然可以理解，做到Oracle BAM那么不编程就实现实时确实很难，但是感觉Oracle的设计方向有问题。把东西封装的太死，花大量时间做功能的封装，几乎没有任何扩展，这样的好处是如果只用到了它提供的功能，万事大吉，做的还快，但是一旦它的功能没法满足需求，那么就完蛋了。
1.Report的产生只能按照BAM提供的套路，直接从DataObject里生成，提供的套路有限。大概就是sql功能的限制版，限制只能在一个DataObject上操作。 经常遇到的问题是，为了某个report建了一个DataObject； 之后的需求要用同样的数据生成另外的report，但是因为BAM提供的套路有限，可能这个时候的数据格式就没法生成我们要的report了，就只能再建一个DataObject。造成大量数据重复，集成复杂化。BAM对比BIRT的一个不足是，BIRT可以从一个SQL的执行结果里生成report，这样SQL就可以对数据进行一些预转换来满足业务要求。BAM没有类似的功能，考虑到BAM需要截获数据的变更，所以通过sql来做确实有点困难，但是还是希望有个类似的功能出来。
2.Report的style只能在页面上的那些选择之类来更改，没有一个统一的CSS。 这样如果大老板希望所有report的颜色之类变变，那就只能把自己当苦力，一个一个改了。当时确实碰到这个问题，好在被TL挡住了，不然要累死。
3.BAM提供一个基于web的report编辑器。report里的view的布局之类也在web上做，用鼠标托拉调整大小，对齐之类。没有提供任何帮助的工具，没有坐标，没有水平线，垂直线，百分比，或者直接输入值的地方。反正什么都没有，想要把页面布局的好看些那就哭去吧。好在后来我做了个小工具，把report先导出来，导出的文本其实是个XML，把report内容的部分截出来，把< > & 之类的字符按XML转义的替换一下，生成一个新的xml，直接更新xml的内容，可以直接调整大小，颜色之类。完了把字符替换回去，并入原来的XML再导入到BAM。
4.动态性不足，没有地方让用户可以自己输入javascript之类来对页面进行些自定义的操作。虽然BAM生成的也是html，但是Oracle把这些都封装死了，没法潜入javascript ;再比如calculator field，其实也可以做到用写动态语言自己写，现在只能用BAM的功能，就算对字符串进行简单操作都变得很困难。
5.bug太多，产品还不够稳定；封装太死，提供的功能的一致性不够强。很多我们认为它会提供的功能最后发现没有，做任何事情前都要亲手做一下，切切实实的试试才能知道到底能不能做。比如，一个Row Group里面不能包含另外一个Row Group; Row Group的title字体没法改（可以用3里提到的那个工具改）；Drill Across的参数不能含有 ‘,’(BAM在javascript里写死用这个作为参数分隔符)；Drill Across不能用Calculator field作为参数等等。