穷人的通用OLAP方案III--JPivot表现层

   JPivot 是Mondrian的表现层TagLib,一直保持着良好的开发进度。   已经好久没有用了,趁彻底忘记以前,把小小的心得记下来。

  1.汉化   1.1 查找所有resources.properties文件,汉化为resources_zh.properties文件   1.2 native2ascii resources_zh.properties resources_zh.properties   1.3 查找WEB-INF/jpivot下的所有xml文件,汉化为xxx_zh.xml

   2.架构   JPivot的架构看似另类,但其实都是精明的选择。   2.1 使用XML/ XSLT渲染OLAP报表      JPivot 使用 WCF (Web Component Framework)  ,基于XML/XSLT来渲染Web UI组件。这使它显得十分另类。不过,OLAP报表这种非常复杂但又有规律可循的东西,最适合使用XSLT来渲染。虽然程序员和编辑器都很不喜欢这种Martin Flower口中有点LISP形式的语言,但Transform Engine这时候的确能比Template Engine(Velocity,Freemarker)更高效的处理OLAP报表及其导航系统的显示。     2.2 完全基于JSP+TagLib     JPivot另外一个可能使人不惯的地方是它完全基于taglib而不是大家熟悉的MVC模式。但如果不基于tabLib,基于任何MVC框架都会使其失去通用性,担不起Mondrain唯一表现层的重任,而且,MVC其实不一定需要那些框架(后述)   2.3 典型的流程及模式:

       打开JPivot自带的sample,查看index.jsp文件,典型的流程如下:

     1,用户发出 testPage.jsp?query=modrain的请求     2,testPage.jsp上的<wcf:include>根据query参数,匹配/WEB-INF/query/下的modrain.jsp来获取数据       

     3,modrain.jsp上的<jp:mondrianQuery id="query01">查询数据,放入到query01变量中

     4,testPage.jsp上的<jp:table id="table01" query="#{query01}"/>根据query01的结果(领域数据) 准备显示OLAP表格所需的数据(显示数据)

     5,testPage.jsp上的<wcf:render ref="table01" xslUri="/WEB-INF/jpivot/table/mdxtable.xsl"/>根据table01的结果,使用xsl,渲染出OLAP表格。

     6,循环第4,5步,使用<jp:navigator>等tag准备navigator,chart的数据然后用<wcf>渲染出图表和导航系统.

     整个流程,第2步的testPage充当Controller调用第3步的Model层,然后第4,5步 执行Martin Flower讲的Transform Engine两步渲染模式----先从领域数据(比如一些java bean)中转换出格式整齐的,需要显示的数据(比如一段xml),再用xsl将其渲染为最终的表现形式。

时间: 2024-09-14 00:44:21

穷人的通用OLAP方案III--JPivot表现层的相关文章

表现层框架Struts/Tapestry/JSF比较

js|比较 Struts/Tapestry/JSF是目前J2EE表现层新老组合的框架技术.从诞生时间上看,Struts应该比较早,使用得非常广泛,Tapestry 3.0逐渐引起广泛的重视,正当Tapestry即将大显身手时期,SUN推出JSF标准技术,虽然JSF一开始推出尚不成熟,留出了一段空白期,但是随着JSF1.1标准推出,JSF开始正面出击,粉面隆重登场了. 其实,JSF和Tapestry也并不是那种头碰头的相同竞争性技术,两者还是各有侧重点的,不过比较细微,但是这种细微点在实现一个大工

符合oo惯例的表现层控制 [曹晓钢]

控制 Hibernate的reference的副标题叫做:符合java惯例的O/R 持久化,这揭示了目前三层结构的重大问题,就是三层的不统一.到目前为止,仍然难于在web界面上实现C/S模式中"master-detail","lookup"的快捷的用户交互. 目前常见的web application的结构,包含web browser/application server/database.database占据主流的仍然是经典的E/R模型,这个模型是基于行集的,因此在

表现层上的快速开发

问题描述 表现层上的快速开发是用JSF好,还是EXT好? 再有JSF有很多实现框架,如myface,icefaces,richfaces,ajax4jsf等等,到底哪个实现框架是最好的? 另外EXT+DWR好,还是EXT_JSON好?还是webwork写标签?能否给个表现层的最佳快速开发组合?要突出成熟的,快速的特点问题补充:就是都不是很熟悉,想咨询下各位哪个好,再进行选择学习,或者jsf可以和EXT结合使用?或者还有其他好的表现层框架?谢谢 解决方案 EXT+DWR不错,但是也好费劲的,不够敏

表现层框架之争 JSF与Struts框架的异同

js Struts和JSF/Tapestry都属于表现层框架,这两种分属不同性质的框架,后者是一种事件驱动型的组件模型,而Struts只是单纯的MVC模式框架,我们下面进行详细分析比较. 首先事件是指从客户端页面(浏览器)由用户操作触发的事件,Struts使用Action来接受浏览器表单提交的事件,这里使用了Command模式,每个继承Action的子类都必须实现一个方法execute. 在struts中,实际是一个表单Form对应一个Action类(或DispatchAction),换一句话说

用NoahWeb表现层制作动态网站

web|动态 第一天开始之前先和大家介绍点NoahWeb概念吧:NoahWeb有两种可以互补的语法:表现层和逻辑层,其中表现层是专门用来控制表现效果的,指令非常少.一共13个指令,如果按功能来分的话就更少了!一共才9个,呵呵,很少.别小看这13个指令,学会使用这13个指令就已经做出各种漂亮的动态网站.别告诉我你不知道什么是动态网站!动态网站就是网页内显示的内容是来源数据库的,页面内容会根据数据库内容动态显示在网页里面. 如果需要了解更多NoahWeb的内容,请访问其主站:http://www.n

表现层模式-MVC

在前面简述了从服务层到数据层参见架构设计目录.剩下了表现层,一个再好的中间层表现也必须有一个用户界面,提供和用户交互,将用户行为输入转化为系统操作,进入后台逻辑.在当下RAD(快速应用开发)工具的支持下,我们可以比较快速的完成UI设计,RAD追求所见即所得的快速反馈,快速应用.表现层也有一定其固定的逻辑(格式化,数据绑定,转化等等,称为UI逻辑)和界面展现.这里UI逻辑指的是所有用来处理数据显示在UI界面的逻辑和,将UI用户输入行为转化为中间层指令的逻辑,负责UI和中间层数据流和行为的转化.很多

有理化表现层

简介 多年来,由于各种原因,IT界已经习惯了一些很离谱的设计模式,这恰恰成为全新时代创建优秀分布式应用的巨大障碍,我们由此有必要更新对目前表现层实现技术的一些看法.本文中,我们想要表述的观点是由web应用表现的整个瘦客户端其实很傻,应该摒弃.我们这么认为的原因,那还得从九十年代中期,web刚刚兴起的时候开始说起. 历史 随着Web的一夜兴起,几乎同时出现了两种背道相驰的开发: (1)作为无处不在的客户端"应用平台"成就了浏览器的绝对重要性,应用因此很容易部署:(2)各商家间的分裂剥夺了

使用View Model从表现层分离领域模型

Model-View-Controller(模型-视图-控制器,MVC) 模式将你的软件组织并分解成三个截然不同的角色: Model 封装了你的应用数据.应用流程和业务逻辑. View 从 Model 获取数据并格式化数据以进行显示. Controller 控制程序流程,接收输入,并把它们传递给 Model 和 View. 与其它设计模式不同,MVC 模式并没有直接反映一个你能够编写或配置的类结构.相反,MVC 更像一个概念上的指导原则或范型.概念上的 MVC 模式被描述为三个对象 -- Mod

J2EE表现层设计思考

设计表现层时需要考虑的几个问题 开发者在设计表现层时,可以使用不同的模型,这时需要考虑一些相关的设计问题.这些问题和模型关系的紧密程度也各有不同,它们可以影响系统的各个方面,包括有安全.数据完整性.可管理性和扩展性.虽然这些设计问题大部分都可以用模型的形式表示,但我们不打算这样做,因为这样更为抽象,我们选择以非正式的文档形式表示.我们只是根据不同的模型,将每个需要考虑的问题列出来. Session管理 用户Session指的是跨越一个客户和服务器多个请求间的一个对话.我们将在以下部分根据用户Se