传统上报表引擎主要完成两项工作:结构描述和结构转换。一般报表设计人员通过可视化设计工具完成对报表结构的描述,然后报表引擎根据这些描述生成不同格式的报表文件,如PDF格式,XLS格式等。这一图景中报表设计工具扮演着关键角色,因为它不仅仅是向用户提供一个直观的界面,更重要的是配置过程本身就是一种分步骤的结构构造过程。理想的情况是用户指定报表中具体有哪些单元格,表格具体有哪些列,而在运行期报表引擎负责向单元格中填充数据。但是对于设计期只能进行动态描述,无法预先确定所有结构元素的报表(例如交叉表的列只能在执行时确定),这种报表模型就会出现问题。一般处理方式都是在报表引擎中内置 ...
    描述所关注的是“what”,而运行所关注的是“how”。在现代软件开发中,描述信息作占的比重日益加大。甚至一种极端的倾向是把所有业务逻辑都写在各 种格式的配置文件中. 配置文件目前多采用xml格式,它的优点是自说明的:属性名直接标示了其基本含义,但是这也在一定程度上加重了命名的负担, 造成了配置文件的臃肿。因为在普通的程序语言中,可以用来传递信息的结构更加丰富,例如参数的相对位置,参数类型, 匿名函数, 指针引用等。而一般配置文件中没有定义合适的继承,封装等抽象机制,很难如同普通程序语言那样进行有效的结构压缩 ...
   在商业产品开发中,如何有效的控制同一产品的多个衍生版本是一个非常重要的问题。客户的需求是多样化,差异化的。这些差异有些很小,可以通过参数配置,资源装载,skin切换等方式加以吸收,而有些则要求对界面布局和程序逻辑等作出较大调整。Witrix开发平台在系统基础架构方面为程序的客户化提供了有力的支持。    1. 多版本控制的关键首先在于系统良好的模块划分。因此Witrix平台的beans,auth-map(权限归约规则)等配置文件格式都支持import/include等基础的分解策略,字符串资源和错误码映射等支持多重定义文件,而对于sql.xml( ...
web程序需要完成  html <--> java 之间的映射,在界面越来越复杂,越来越多变的今天,这项工作也变得越来越困难。按照级列设计理论的观点,我们应该去寻求一些中间的过渡步骤。在 witrix平台中,tpl模板引擎正扮演了这种中间角色。通过tpl模板我们实现了如下映射路径 html <--> tpl <--> java 注 意到这里html与tpl之间,以及tpl与java之间的映射都不是trivial的同构关系,而是都可能存在着复杂的运算过程,从而实现了html与 java映射过程中复杂性的分解与均摊。tpl与java之间的关联主要通过 ...
    在witrix平台中,validate.js提供了完整的客户端输入校验框架。其基本思想是为每个输入控件指定验证函数(validator属性),在提交Form的时候自动调用该验证函数即可。 <form action="test.jsp"> <input type="text" name="userName" validator="js.validate.checkNotEmpty(value,'用户名')" /> <input type="button" value="submit" onclick="js.validate.s ...
witrix平台中的tpl模板技术是一种通用的xml动态标签技术,不仅可以用于文本生成,而且可以用于任何需要动态标签的地方,例如工作流引擎 的配置和执行脚本。tpl模板引擎采用的不是jsp tag的标准机制,而是重新设计并实现的。在开发的后期,因为jstl标准出现,我们对标签的命名作了一定的修改,以尽量符合标准的调用接口。tpl模板 语言完全符合xml规范,其标签定义都是完全独立开发的。在开发tpl的时候,我们甚至没有看到任何类似于c:forEach和c:if的标签设计。但是 我们发现,tpl的动态处理功能与jstl虽然命名不同,但是基本是等价的,所以修改是非常直接的过程。 FreeMark ...
    tpl自定义标签的设计目标之一是尽量减少配置说明项. 在tpl标签库中, 标签定义格式如下     <标签库名称>         <自定义标签名 demandArgs="argA, argB"             importVars="varA, varB"      &n ...
    witrix平台中的tpl模板技术的重点在于标签定义的设计, 在于如何最大限度的发挥xml格式的表达能力。     tpl自定义标签的基本结构如下:     <Namespace:TagName tpl:tag="realTagName"         tpl:noborder="${booleanExprInCompileContext}"       &nb ...
  hibernate等O/R Mapping软件包中使用javabean来作为数据的载体, 但这些bean一般除了get/set等数据访问方法之外没有什么其它的业务方法。 前一段时间有人认为这是所谓贫血的领域模型(Anemia Domain Model),引发了一场讨论。 其实这些bean的作用仅是表达了领域内的数据关系, 本身并不可能作为完整的领域模型层存在。 在数据层,我们所需要的是数据对外暴露,因为我们无法预知这些数据的使用方式, 就象是实验数据发表出来以后你无法预知别人如何分析一样,这时信息流是开放的,向外的:信息在这里,放马过来吧。 而在业务逻辑层,复杂的逻辑控制交织在一 ...
    在程序中需要返回一个数据集合的时候, 应该尽量选用标准的Java集合类接口,例如List, Map等. 有时也见到有人选择返回Iterator对象, 一般情况下这不是很好的选择. Iterator对象的功能有限, 而且存在一种即时消费的特点, 我们一般不能把一个Iterator保存起来留待以后使用. 而且JDK提供的集合类也不能从Iterator直接构造出来,例如没有 new ArrayList(myIterator), 这样为数据复制造成一定的困难.     Iterator在理论上的好处之一是可以支持延迟加载数据, 但是 ...
交叉表(Cross Table)的基本特点是具有横纵两个自由延展的维度,而平面表结构只有一个可延展的维度,因为平面表的列名和列数是确定的。例如,地区的产品销售数量,在平面表中表达为 district_id product_id sell_num 如果表现为交叉表,则为            productA  productB districtA   sellNum   sellNum districtB   sellNum& ...
数据导出的功能大致可以分解为三个部分: 1. 从数据源读取一条记录 2. 将一条记录导出为指定格式 3. 循环调用1和2 首 先我们需要一种机制来对外暴露数据源(一种Container)中的数据,Iterator模式恰能满足要求。其次,我们需要一种机制来对一系列数据进行 处理,这对应于Visitor模式。第三,在组合Iterator模式和Visitor模式的处理过程中,我们需要表达出平面表数据集的基本特征。 在witrix平台中,平面表数据导出和转换通过TablePageProcessor对象来完成, class TablePageProcessor{  IPageViewer vi ...
分页的功能由两部分组成:取数据和计算分页。其中取数据的功能由IPageViewer接口实现 interface IPageViewer{  int getTotalCount();  List getAll();  int listPage(int startPos, int maxCount); } Pager是用户调用时的接口 class Pager{  public List getAll(){}  public List listPage(){}  public int getPageCount(){}  publi ...
java中最常用的数据结构类型是Map和List, 它们也是Container的两种基本模式,一个是根据特征值定位,一个是根据地址定位。 它们共同的一个特征是表达了数据之间的直接的,短程的一种相关性。另一种常见的数据结构Tree则表达了数据之间的一种长程的关联:根节点与其所有层次上 的子节点之间都存在着关联。 文件系统,组织机构, XML文档等都可以对应为Tree数据结构。在描述树形结构的时候,我们经常使用XML文件, 但是XML文件在程序中操纵起来并不方便,这其中的一个重要原因是XML是面向文档的,即操纵XML的API返回的和使用的都只能是文本字符串,而不能直 接使用程序中常见的其他数据结构 ...
有人认为jsplet中使用session是个缺点,关于这一点,我想起一件以前听来的事情。我们都知道Linux的内核是常驻内存,不换页的(不知道最 新的内核是否已经有所改变),Torvalds认为内核换页对系统性能有巨大影响,是愚蠢的想法,所以Linux内核不能换页。据陈榕说,NT内核是可换 页的,而微软内部有一个小组,专门编写工具,对已经编译好的操作系统二机制代码进行优化,调整,最终结果是NT内核可以换页,但几乎不换页,这才是微软可 怕的技术实力。 对于简单的应用,session可以随意使用,而对那些性能要求极高的应用,每一个系统架构师都会如履薄冰,简单的依靠全局Cache不是真正的解决方 案 ...
tpl是witrix开发平台中的动态xml标签技术,其基本特点表现为如下三个方面:1. 执行能力 xml本身只是对数据的描述,而没有循环和判断的能力。 在tpl中<c:forEach>和<c:if>标签可以完成程序语言的执行功能,并定义了<c:tile>, <c:iif>等更方便的标签。 2. 抽象能力   获得抽象能力,首要的一点是使得创建新概念的成本极低。很少有人大量开发jsp tag,原因就是开发tag过于麻烦,而且调整不方便。另外开发出的tag如果粒度太小,大量使用的时候是对性能的致命伤害。&nbs ...
关于jsplet中的object生命周期的管理以及使用拉模式,如果套用现在流行的设计术语,那就是涉及到所谓的IoC设计(控制反转) IoC 的Container现在很受追捧, 但真正的IoC设计思想并没有引起大家的重视。也许大多数人使用的都是成品吧,以至于把成品的功能等价于其所依赖的设计原理。Spring等所建立的 IoC更准确的说法是Dependency Injection,只是IoC的一种体现。其基本思想是一个对象并不控制所有与它相关的部分,而是把控制权交给使用对象的人。这里重要的就是控制流(信 息流)的反转。 对象生命周期的管理也是这样,并不是由一个Manager猜测用户是否使用该对象, ...
jsplet中的对象化并不是一种巧妙的trick,而是一种设计上的必然。现在大家言 必称OO,可OO到底意味着什么,除了书本上的话语,你能不能用自己的话描述一下,能否体会到那种必然。OO如果是一个有效的概念,它在软件以外的领域是 否有着对应。按照早期教科书的说法,OO是为了模拟现实世界,这种说法只是反映了设计上的一种困境,一种思想上的贫乏。面向对象最直接的意义在于标示了状 态与行为之间的耦合,此后在程序中可以用一种显示的,一致的方式来操纵这个集合体。在界面上,我们看到一个组件,在模型层,我们看到的还是那个对象,在配 置文件里我们还能清晰的辨别出它来。可在webwork这种面向action的框架 ...
引用:如果在Action Centric的框架,要避免两个访问点,可以这么定义。 view.do?&templateName=a &objectName=/@Demo&objectEvent=test 这 种做法就是程序自己处理而不是框架支持了。我说过,工作就是那么多,只是框架做什么和程序作什么的分工而已。说jsplet是page为中心也不太准确, jsplet是以对象为中心,只是指定了希望使用的视图页面而已。view.jsp放在前面只是jsp实现上的一个问题, 引用:Action Centric 确实比较麻烦,必须同时传入角色列表 和 用户列表的 分页信息。 ...
jsp本身提供的是一个有限状态机模型(FSM),Web访问模型直接体现了这一点: action?XXXX。 action对应于方法名,XXX是方法的参数。在这个访问模型中没有指出状态存储在什么地方,因为它假设后台是一个整体,构成一个巨大的状态集。 但 这种模型注定是过分简化的,所以会有很多的发展。发展的方向就是逐渐精细化,识别出相关的部分,把它们组织到一起。其实可以从各个框架的开发过程来看出这 种演化的过程。 Struts最早只有一个全局配置文件,现在多了一个模块的概念。WebWork是在Struts之后设计的,提供了一个所谓的package的概念,将 一堆action和interceptor ...
   在Jsp Model 2模型中, 用户的所有请求提交给Controller Servlet, 由Controller进行统一分配, 并且采用推的方式将不同的UI显示给用户。 这种推方式在很多人看来是一种优点,因为在Struts等MVC实现中具体推送的UI可以在配置文件中配置,配置完成后还可以通过一些可视化分析工具得到 整个站点地图。在Model2模式中基本的访问格式为:       action.do?其他参数   我 本人从未应用过Model2模式,但与我们的jsplet框架对比,我认 ...
在witrix平台中访问数据库最直接的方法是使用edu.thu.db.SQL类。基本用法如下://  设定数据库连接参数, 连接可以通过java.sql.DriverManager 和 //javax.sql.DataSource等多种方式建立,并支持数据库连接缓冲池。TransactionMode db = new TransactionMode("default"); // 设定数据库连接参数SQL sql = SQL.begin().select().field("id")          ...
canonical
搜索本博客
最近加入圈子
存档
最新评论