快逸报表（Quiee Report）

       报表很大，看的时候就需要滚动条了，但是一滚整个报表都动了，表头也看不到了，这看着就太麻烦了，老要来回来去地拖上拖下拖左拖右。
       EXCEL想到了这个问题，提供了冻结窗格的功能，可以把上边或左边的几列固定下来，这样，再怎么滚动表头总是不动，就不会看走眼了。
       可惜的是，在WEB上的HTML表格却没直接提供这个功能，它的TABLE只能整个地滚。怎么能做出象EXCEL那样冻结表头的效果呢？

       简单的想法，是把表格人为地分为上下两块，上半截表头不动，下半截表体自己滚动，这不就完了吗？看起来也不算多麻烦了。
       可别高兴得太早，这仅仅解决了上边的表头，如果我们足够不幸的话，会碰到即长且宽的表格（概率不小），这时还需要有个左表头。分两块显然不够了，那分四块行吗？左上角一小块不同的，其右边是上表头，下边是左表头，右下部分是表体。
        事还没算完，这几块之间还会有关联。比如表体横向滚动时，需要让上表头跟着一起滚动，否则上下就错位了；同样，纵向滚动时左表头也要与表体同步。这就还要写一堆JS代码让这几片表格一起滚动。
       哎，可麻烦死了。

      不幸中的一幸，采用了快逸报表，这事就轻松多了，只要两步：
                1． 在设计报表时将需要冻结的行和列选中，设为表头行和表头列。
               2． 在发布报表时的tag属性中设置needScroll=”yes”，还可以用scrollWidth和scrollHeight设置滚动区域的大小。
      上面说的麻烦事都被快逸报表做完了。

看一下效果：

一切OK，搞定！

注：这是快逸开发版中提供的功能。

任务背景:

        在业务系统中，一些基础数据的中文名称可能存在变化，而这些基础数据可能在多个事实表里被引用，一旦中文名称发生了变化，要求历史数据也同步跟着变化，因此如果事实表里引用的是基础数据的中文名称的话，必然要求历史数据进行同步修改维护，工作量巨大。

        为了解决这个问题，程序员设计基础数据表的时候，往往增加了代码字段，事实表里引用基础数据的代码值，在报表中根据基础数据表的内容动态匹配显示成中文。这样，只要保持基础数据的代码值不变，中文名称随意改变都没有关系。

于是，问题出现了。

面临困难:

        最简单的匹配方式，就是把基础数据表和事实表根据代码值关联起来，在报表的单元格里直接显示基础数据的中文名称，这种方式，不需要复杂的编程，客户端也不需要写javascript脚本进行动态匹配，是最简单的方法。但是，如果该单元格的值要被其它单元格所引用，这种方式就不行了，因为这种方式单元格里存储的就是中文，而由于事实表里存储的是代码，因此引用的时候往往需要引用代码。

        于是提出了新的需求：单元格里存储的是代码（便于被其它单元格引用），但是显示成中文。

        这种情况下，就需要写网页上的脚本，来进行动态匹配。一旦基础数据的记录数很多，这种脚本还非常长，导致网页很大，下载速度慢。

        当然，上述还是比较简单的显示值匹配。另一种更加复杂的，中文名不是存储在一个字段里，此时显示值需要通过表达式计算出来。举例来说，人口普查行业的人员表，为了便于根据姓氏得出各种统计数据，往往把姓和名存储在不同的字段中，于是匹配显示值的时候，要先把姓名计算出来再和代码值进行匹配显示。

        前面讲到的还仅仅是显示，在进行数据录入的时候，一样存在显示值的匹配问题，我们不可能让用户输入代码，只能让用户选择中文名，于是出现了下拉框。可是一旦可供选择的项太多了，下拉框无比长，用户就没法选了，眼睛都会看花。于是又提出了下拉树，即把下拉选项根据业务逻辑划分成多个类，每个类下又划分成多个子类，这样一级级的查找选择，速度快多了。

        当然，也有提出动态过滤的，即前面一个下拉框比如省份选择后，后面一个下拉框比如城市就进行动态过滤，只下拉出前一个省份所包含的城市，大大减少了下拉选项的个数，方便用户选择。

        总体来说，一个很简单的代码与显示值的匹配问题，在实际业务系统中却会引发无数的问题。上面仅仅列举了比较常见的几种。如果都要程序员自己开发，工作量太大了，而且很难方方面面考虑周到。因此建议采用快逸报表，快逸报表为此提出了全面的解决方案：

实现步骤:

1、 单元格提供了真实值和显示值两种属性，均可灵活定义表达式
2、 提供了下拉列表、下拉视图、下拉数据集、下拉树、动态过滤等编辑风格，定义简单，使用灵活，能够满足大部分业务系统的需要。

效果演示:

        报表开发只是应用程序中的一部分，而非全部，因此Web报表软件的集成性就显得非常重要了。
　　传统的Web报表软件无一例外地都提供了一个独立的报表服务器。采用独立服务器时的，应用结构如下图：

　采用独立服务器的不便：

• 独立的报表服务器，与应用程序的沟通是通过网络协议，严重降低性能；
• 无法享受应用服务器的各项优势功能，包括集群能力、连接池的管理能力等；
• 报表服务器独立的用户权限户管理机制，无法适应各种行业、各种应用独特的用户角色管理需求，不够用却又迫使应用程序遵守它的规则；
• 编程接口太少，控制力度弱，难于整合。

        作为专业的Web报表解决方案提供商，快逸报表软件以Jar包的形式提供给程序员集成，没有独立的报表服务器，没有应用架构，也没有独立的用户角色管理机制，极大的方便了程序员的集成，其应用结构如下：

没有独立服务器的好处：

• 快逸报表软件的服务器作为应用服务器上的应用或JAR包提交，可与应用程序无缝结合，达到最高运行效率；
• 可共享应用服务器集群能力和连接池管理；
• 统一部署，直接使用Web应用已有的用户角色管理机制，不存在两套管理机制无法兼容的问题，提供统一的登录界面，最终用户不需要登录两次。

        许多Java报表开发工具，特别是有点BI色彩的产品都会向用户宣称产品简单易用，只要鼠标拖拽几下就能画好报表了，甚至能让业务人员随心所欲地制作各种统计报表。
        Java报表开发居然已经变得这么轻松简单了？！
       事实的现象是：程序员依然在与各种报表进行艰苦地斗争，而买回家的报表工具也好、OLAP产品也好都很少有机会走出科技部门，业务人员也还在使用朴实无华的EXCEL。
       希望业务人员采用这些纯技术工具制作各种统计报表有点一厢情愿，比较简单的Web报表（行式分组或简单交叉）当然可以，通过一定的向导功能再配有语义层一般都能完成。而大多数的复杂报表是让程序员看了都怵三分的东西，让不理解数据结构关系的业务人员给“拖拽”出来，基本上是不可能的。
      拖拽只能摆摆数据项的位置，对复杂统计报表必须要解决的汇总条件、分类规则、运算公式不会产生任何帮助，到头来还要靠写抽象的表达式解决，这需要制表人员事先理解报表的运算模型，不比编代码简单多少（如果哪一天业务人员都会做这个事了，程序员也就可以失业了吧？）而且拖拽连摆位的事情也做不好，当前的报表工具的样式编辑许多是基于控件的，这种方式是一个一般性的图元编辑方案，完全没有体现表格的规律性，理论上讲是可以画出报表，但非常累，还常常对不齐。而真正成功的表格产品象Excel却不是采用控件拖拽的方法。
        那么业务人员就不可能自己制作Web报表了吗？当然是可能的！但是直接基于通用的技术型报表工具只能做很简单的报表，而复杂的行业报表则必须采用有行业色彩的程序工具才可能，也就是说需要由行业软件开发商，基于某些技术型的报表工具，把行业经验融合进去，规定好报表的各种模板式样或向导，由业务人员去选择填写相应的参数和指标就可以生成各种复杂的统计表，这个工作的难度取决于该报表开发工具的功能和可集成性。
       拖拖拽拽画报表，做起来并不象说起来那么轻松。

       谈BI展现工具的部署与JAVA

       BI的前端展现工具，或者说报表系统，在应用系统中占据着重要的地位。
       报表系统的部署，有多种方式：
        一种独立服务器，以Business Objects(BO,Crystal Report),Heperion(Brio),Cognos等国外产品为代表的，它们的服务器是单独部署的，与应用程序之间通过某种协议沟通信息。这类服务器功能比较强大，但同时安装也比较复杂，特别是在非Windows的操作系统下，除个别纯JAVA产品外，大部分产品在UNIX下部署困难，个别产品至今没有稳定的成功案例。这种方式还有个问题，由于报表服务器与应用程序之间要通过网络协议，会导致性能下降，而且不可能通过网络协议提供较多的API接用，对报表服务器控制力度较不够深入。对于报表这种无事务的服务而言，采用独立服务器并不是一个好的选择。
        第二种是控件嵌入式，这又会走另一个极端，干脆所有的报表计算都在客户端的控件上。这样服务器端基本上只是负责把数据取出来送出，其实没什么代码，部署就相当简单。但是缺点是控件安装、更新都给用户带来很大负担，有时也可能带来安全性方面的问题。而且这些控件也全都只能在windows下运行，无法把高强度的运算转移给服务器。
       第三种是嵌入式服务器，特别是纯Java的产品，以Jar包形式提交。这类产品一般会在前端提供HTML而不是控件的报表展现方案（关于报表的展现，请参见… …)。由于Java的平台无关性，Java报表系统可以轻松地部署在各种平台上。而且嵌入式的服务可以无缝地与应用程序结合在一起，达到最高的运行效率，而且可以充分利用应用服务器的集群共享能力，控制力度也非常深入，还能够与应用程序统一部署安装，整体结构非常自然。

        毫无疑问，在BI展现工具的上述各种部署方式之中，嵌入式的Java报表应该是最容易部署的，也是最有利于用户的投资保护的。

第三方观点－快逸报表的优缺点

优点之一：纯JAVA，对Java 应用支持良好。 纯 JAVA 的产品，能够跨平台，支持Windows ，unix， Linux 平台，能够与 java 应用很好地集成。

优点之二：产品成熟，功能全面。 制表能力方面虽然比不上润乾报表，但跟杰表、水晶、数巨、 Style report等报表软件比较还是绰绰有余，再加上比较全面的填报解决方案、打印和输出能力，足以在低端市场上跟这些工具较量一下。

优点之三：便宜。4500元的价格，确实很有吸引力。

优点之四：专业的本地化支持。 背靠着润乾公司的技术优势，产品自主创新，专业的报表人才支持，还是相当有说服力的。

优点之五：零成本升级。

快逸报表与润乾报表的各版本兼容，当有更高的报表需求时，可以无缝升级至润乾报表的各版本，无须修改已有应用。对与润乾公司初次合作的用户来说， 快逸不啻为一个好的选择：如果不满意，4500元对企业来说基本算不上成本。

下面也要谈一谈快逸报表的缺点。

缺点之一：可能会冲击润乾报表的销售。都是润乾公司的产品，快逸报表的价格很明显更便宜，客户在选择时也许会相对保守。

原文出自：Report99－快逸报表的优缺点，有内容上的更新。

做报表很长时间了，最近发现一个比较奇怪的现象：各家软件工具使出各种手段做广告、吸引注意力，但是受到程序员热烈追捧的反倒是 Jsper report＋ireport这样的免费、开源的JAVA工具，几个开了专版讨论JAVA报表的论坛里面都是热火朝天，发问者众。
这是为什么？
Jsper report＋ireport是纯 JAVA 的报表软件，相信无论出于何种目的的使用者，看上这两个产品的原因无非是因为：免费（这是最重要的）、专业的报表软件、纯JAVA的。看来大部分人都意识到应该用专业的工具而不是堆代码来完成报表了，这是个进步。纯JAVA的报表现在也有很多了，快逸报表、Fine report、润乾、 Style report等等。看来决定性因素只有应该：免费。
报表软件，到底免费与收费孰优孰劣？
首先，免费的Jsper report＋ireport能给我们带来什么？答案显而易见：拥有了一定可用性的报表软件；开源的代码能够拥有灵活的可定制能力和完全的控制；最重要的是成本低。
事实果真是这样吗？
Jsper report＋ireport的制表能力实在一般，老外的东西，本质上就不符合咱的需求。被水晶这种产品培养出的报表习惯，报表似乎就该这么做，做不出来的报表似乎就应该写程序，再要不请客户修改需求吧。改不了？写代码。所以用工具的结果还是吭哧吭哧写代码。
在论坛里，象“请教高手某某问题如何解决”这类的帖子比比皆是，发问者往往也是在线等答复。问题如果有解也就罢了，无非是有答案的人什么时候给答案，运气好的在线能等到，运气不好的那就等着吧。如果碰到的正好是个没解的问题呢？或许会有热心观众参与讨论，解决办法还得自己想。掰着指头算算，花在这问题上的时间、人工成本，够不够买一个收费的工具？
最近听说Jsper report＋ireport的所有帮助文档是收费的，文档倒是相当细致，需要花大量的时间阅读。这才明白：所谓开源不可能真的有人那么无聊为人民服务，说白了还是要挣钱的，否则产品的后续研发怎么办？呵呵，听说文档都是英文的。
收费的报表软件如何呢？
至少在你有问题的时候能找个人支持你吧？！
至少还能理直气壮地说“我买了你产品，你就得帮我解决问题”吧？！
至少还能在某种程度上偷工减料说“这表我整不出来，你过来和我们一起做吧”？！
从社会的分工的趋势来看，工作一定是越做越专业，分工一定是越来越细致。就报表行业看，最理想的情况应该是：专业报表厂商应该是开发商的一个外围研发中心，每家开发商出一些钱（在项目中使用报表软件）给报表厂商，而厂商则专注于为各家合作伙伴解决报表问题。
所以，再碰上选择报表软件的时候，一定不要怕跟老板倾诉： 报表制作其实是很专业的的活，花钱买一个工具比用开源工具划算，这跟你的开发能力无关，你要做好的是你的业务系统。

引自博客：JAVA报表。

作为报表开发工具必不可少的一个功能，快逸报表提供参数机制。

通过使用参数，用户可以方便地定制不同报表，灵活地组织各种报表查询条件，也可作为表达式的条件使用在报表的任何地方，以此来控制报表的数据范围、显示方式、是否可见等等。

快逸报表还提供比参数功能更强大的宏。

与一般意义的参数不同，宏没有数据类型，可用于替换报表表达式的任何部分。

如：SQL语句中的整个WHERE子句作为一个宏，类似SELECT…FROM…WHERE macro。计算时，报表运算器会自动将macro替换成传入的宏值（表达式、字符串）。

同样地，FROM后面的表名，甚至整条SQL语句都能作为宏来传递。

恰当使用宏，能够制作出非常灵活的Web报表。

实际应用中，我们碰到这种情况：用户的报表希望以某个字段、正 / 逆序分别输出。出于设计方面的原因，必须采用数据库的排序运算，即用 SQL 的 Order By 子句控制，但该字段不是数值型，只能用 ASC 和 DESC 控制。

采用快逸报表特有的宏，只要把排序方向作为宏传入Web报表就可以了，否则就只能做两张报表了。

当然，宏在带来方便的同时，也有其缺点，写进了宏的表达式在报表设计期间无法进行语法检查，只能在解析后才能查出错误，使用时必须很小心。

快逸报表突破了传统报表工具软件的思维框架，提供了一种更为便利的权限控制机制。

一般地，每个应用系统都有自己的、带有业务色彩的权限管理模块。

而作为第三方软件嵌入的报表工具软件 ， 只是应用系统的一部分 。 如果它也有自己的用户角色管理模块，势必会产生两种机制之间的整合、沟通。

而现在，大部分的报表工具软件都有自己的用户角色管理模块。

报表开发工具会创建专用的数据表（或者数据适配器、数据源等），将应用程序中的用户信息导入报表系统中，并为这些用户设置报表权限。当应用程序的用户信息发生变化时，需要同步修改报表工具中的用户权限。

其实这是非常不合理的。

用户权限一般都带有很强烈的业务色彩，相同行业里的用户权限尚且不能完全复用，更不用说跨行业的了，而报表工具软件的权限机制没有业务色彩。这就导致了这种机制与应用程序自身的体系常常不相匹配，但又要迫使应用程序向其靠拢，多做了许多无用功。

快逸报表提供全新的权限控制机制,通过参数和宏，完全采用应用系统本身的用户角色信息，来控制用户是否可见、可写某张报表，其控制粒度可以是整个报表、某行某列、甚至精确到某个单元格。

更多请参考：快逸报表－参数和宏、 典型报表－利用宏动态计算。

快逸报表采用的是自主研发的新一代报表模型，与电子表格式和传统工具式均有所不同。

单元格的扩展模型是快逸报表数据模型的基础。

在下图中，B2单元格的值为“list(1 to 5)”。List（）是集合函数，其值为一个枚举数据的集合，在这里的意思就是｛1，2，3，4，5｝的集合。将B2单元格的扩展属性设置为纵向扩展，预览可得：

可以看到：B2单元格扩展出五个单元格，1、2、3、4、5这几个数字顺序填入。编辑时处在B2下方的B4，在预览时仍然在扩展之后的单元格后面。

单元格的扩展能力横、纵向相同，通过扩展模型，我们可以动态取出数据，形成各种灵活的分组、交叉报表。

参考：快逸报表－主格附属格模型 、快逸报表VS同类产品。