1、 JasperReports 一個優秀的Java 閱讀全文
]]>
CSS Negotiation and a Sanity Saving Shortcut. * { margin: 0; padding: 0 } 的學名是Global White Space Reset. 從原文中可以看出這個方法剛問世時是非常火爆的，并且作者建議一定要先破后立，要將清掃差異和重置默認樣式結合起來，這樣才是正確的做法。
為何Global White Space Reset當初風光一時，如今卻黯然銷魂？* { margin: 0; padding: 0 }的成功之處在于，管你三七二十八，統統抹平，人人生而平等！然而其失敗之處也正是因為其威力太大，雖然搗了蜂窩得了蜜，卻惹來群蜂追尾，麻煩無限（因為被抹平的樣式，你得再重新設置回來，比如input的padding等）。這就如西漢一代名將韓信哪，是成也蕭何，敗也蕭何！
2007年，Eric Meyer的一篇文章Reset Styles, 重新喚起了一股reset熱潮。下面是Eric Meyer的一個CSS Reset方案:
1. html, body, div, span, applet, object, iframe,
2. h1, h2, h3, h4, h5, h6, p, blockquote, pre,
3. a, abbr, acronym, address, big, cite, code,
4. del, dfn, em, font, img, ins, kbd, q, s, samp,
5. small, strike, strong, sub, sup, tt, var,
6. b, u, i, center,
7. dl, dt, dd, ol, ul, li,
8. fieldset, form, label, legend,
9. table, caption, tbody, tfoot, thead, tr, th, td {
10. margin: 0;
11. padding: 0;
12. border: 0;
13. outline: 0;
14. font-size: 100%;
15. vertical-align: baseline;
16. background: transparent;
17. }
]]>
AOP（Aspect-Oriented Programming，面向切面編程），可以說是OOP（面向對象編程）的補充和完善。OOP引入封裝、繼承和多態性等概念來建立一種對象層次結構，用以模擬公共行為的一個集合。當我們需要為分散的對象引入公共行為的時候，OOP則顯得無能為力。也就是說，OOP允許你定義從上到下的關系，但并不適合定義從左到右的關系。例如日志功能。日志代碼往往水平地散布在所有對象層次中，而與它所散布到的對象的核心功能毫無關系。對于其他類型的代碼，如安全性、異常處理和透明的持續性也是如此。這種散布在各處的無關的代碼被稱為橫切（cross-cutting）代碼，在OOP設計中，它導致了大量代碼的重復，而不利于各個模塊的重用。
而AOP技術則恰恰相反，它利用一種稱為“橫切”的技術，剖解開封裝的對象內部，并將那些影響了多個類的公共行為封裝到一個可重用模塊，并將其名為“Aspect”，即方面。所謂“方面”，簡單地說，就是將那些與業務無關，卻為業務模塊所共同調用的邏輯或責任封裝起來，便于減少系統的重復代碼，降低模塊間的耦合度，并有利于未來的可操作性和可維護性。AOP代表的是一個橫向的關系，如果說“對象”是一個空心的圓柱體，其中封裝的是對象的屬性和行為；那么面向方面編程的方法，就仿佛一把利刃，將這些空心圓柱體剖開，以獲得其內部的消息。而剖開的切面，也就是所謂的“方面”了。然后它又以巧奪天功的妙手將這些剖開的切面復原，不留痕跡。
Spring支持四種攔截類型：目標方法調用前（before），目標方法調用后（after），目標方法調用前后（around），以及目標方法拋出異常（throw）。
前置攔截的類必須實現MethodBeforeAdvice接口，實現其中的before方法。
后置攔截的類必須實現AfterReturningAdvice接口，實現其中的afterReturning方法。
環繞攔截的類必須實現MethodInterceptor接口，實現其中的invoke方法。環繞攔截是唯一可以控制目標方法是否被真正調用的攔截類型，也可以控制返回對象。而前置攔截或后置攔截不能控制，它們不能印象目標方法的調用和返回。
但是以上的攔截的問題在于，不能對于特定方法進行攔截，而只能對某個類的全部方法作攔截。所以下面引入了兩個新概念：“切入點”和“引入通知”。
”切入點“的定義相當于更加細化地規定了哪些方法被哪些攔截器所攔截，而并非所有的方法都被所有的攔截器所攔截。在ProxyFactoryBean的屬性中，interceptorNames屬性的對象也由攔截（Advice）變成了引入通知（Advisor），正是在Advisor中詳細定義了切入點（PointCut）和攔截（Advice）的對應關系，比如常見的基于名字的切入點匹配（NameMatchMethodPointcutAdvisor類）和基于正則表達式的切入點匹配（RegExpPointcutAdvisor類）。這些切入點都屬于”靜態切入點“，因為他們只在代理創建的時候被創建一次，而不是每次運行都創建。
下面是spring的配置文件 當然aop的配置方式有許多種，這只是其中一種
<!-- 獲取相應的instance對象 并且不被aop攔截 -->
<bean id="oaTaskInstanceService4Log" parent="transactionProxy">
<property name="target">
<bean
class="com.oa.task.service.impl.OaTaskInstanceServiceImpl">
<property name="oaTaskInstanceDao">
<ref local="oaTaskInstanceDao"/>
</property>
</bean>
</property>
</bean>
<!-- instance日志所需DAO -->
<bean id="oaTaskInstanceLogDao" class="com.oa.task.dao.OaTaskInstanceLogDao">
<property name="sessionFactory" ref="sessionFactory"></property>
</bean>
<!-- instance日志所需Service 此接口為 日志的業務操作接口-->
<bean id="oaTaskInstanceLogService" parent="transactionProxy">
<property name="target">
<bean
class="com.oa.task.service.impl.OaTaskInstanceLogServiceImpl">
<property name="oaTaskInstanceLogDao">
<ref local="oaTaskInstanceLogDao"/>
</property>
<property name="sysOperDao">
<ref bean="sysOperDao" />
</property>
<property name="ibatisBase">
<ref bean="ibatisBase" />
</property>
</bean>
</property>
</bean>
<!-- instance日志AOP攔截類 -->
<bean id="oaTaskInstanceLogOper" class="com.oa.task.log.OaTaskInstanceLogOper">
<property name="oaTaskInstanceLogService">
<ref local="oaTaskInstanceLogService" />
</property>
<property name="oaTaskInstanceService">
<ref local="oaTaskInstanceService4Log" />
</property>
</bean>
<!-- instance日志AOP配置綁定 -->
<bean id="oaTaskInstanceLogAutoProxy"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>oaTaskInstanceService</value> //攔截的業務接口 oaTaskInstanceService內所有方法都進行攔截
</list>
</property>
<property name="interceptorNames">
<list>
<value>oaTaskInstanceLogOper</value> //攔截器
</list>
</property>
</bean>
下面是 攔截器oaTaskInstanceLogOper類，采用的是環繞攔截的方式。<bean id="oaTaskInstanceService4Log" parent="transactionProxy">
<property name="target">
<bean
class="com.oa.task.service.impl.OaTaskInstanceServiceImpl">
<property name="oaTaskInstanceDao">
<ref local="oaTaskInstanceDao"/>
</property>
</bean>
</property>
</bean>
<!-- instance日志所需DAO -->
<bean id="oaTaskInstanceLogDao" class="com.oa.task.dao.OaTaskInstanceLogDao">
<property name="sessionFactory" ref="sessionFactory"></property>
</bean>
<!-- instance日志所需Service 此接口為 日志的業務操作接口-->
<bean id="oaTaskInstanceLogService" parent="transactionProxy">
<property name="target">
<bean
class="com.oa.task.service.impl.OaTaskInstanceLogServiceImpl">
<property name="oaTaskInstanceLogDao">
<ref local="oaTaskInstanceLogDao"/>
</property>
<property name="sysOperDao">
<ref bean="sysOperDao" />
</property>
<property name="ibatisBase">
<ref bean="ibatisBase" />
</property>
</bean>
</property>
</bean>
<!-- instance日志AOP攔截類 -->
<bean id="oaTaskInstanceLogOper" class="com.oa.task.log.OaTaskInstanceLogOper">
<property name="oaTaskInstanceLogService">
<ref local="oaTaskInstanceLogService" />
</property>
<property name="oaTaskInstanceService">
<ref local="oaTaskInstanceService4Log" />
</property>
</bean>
<!-- instance日志AOP配置綁定 -->
<bean id="oaTaskInstanceLogAutoProxy"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>oaTaskInstanceService</value> //攔截的業務接口 oaTaskInstanceService內所有方法都進行攔截
</list>
</property>
<property name="interceptorNames">
<list>
<value>oaTaskInstanceLogOper</value> //攔截器
</list>
</property>
</bean>
public class OaTaskInstanceLogOper implements MethodInterceptor{
/**
* 當更新動作發生時的記錄
*/
public Object invoke(MethodInvocation invocation) throws Throwable {
String method = invocation.getMethod().getName();
Object result = null;
if(MODIFY_INSTANCE.equals(method)){//修改日志（業務邏輯 判斷方法）
......//業務操作，進行日志的記錄
result=invocation.proceed();
}else {//不做任何日志
result=invocation.proceed();//調用原來的方法
}
return result;
}
}
/**
* 當更新動作發生時的記錄
*/
public Object invoke(MethodInvocation invocation) throws Throwable {
String method = invocation.getMethod().getName();
Object result = null;
if(MODIFY_INSTANCE.equals(method)){//修改日志（業務邏輯 判斷方法）
......//業務操作，進行日志的記錄
result=invocation.proceed();
}else {//不做任何日志
result=invocation.proceed();//調用原來的方法
}
return result;
}
}
]]>
由于只是初步涉足flex領域，所以只能提出一點自己的看法，并不具有說服力。
cairngorm 前端的控件監聽用戶的行為，只是監聽，并不會做任何反應。控件監聽以后調用Commands來做相應的事情，Command做了所有工作。把業務邏輯委托到 Bussiness Delegates中，Command調用Business Delegate 后，Business Delegate 通過Service Locator來找到相應的RPC services，然后執行實現從服務器端取數據。
在Model Locator 保存狀態并且能使Model檢測到View的變化。這樣一來用戶操作就能直接影響Model。
它的體系主要包含下面幾部分（具體用法就不做分析了）：
1. Business(業務邏輯部分)
2. Command(命令部分)
3. Control(控制部分)
4. Model(數據模型)
5. View(界面視圖)
6. VO(ValueObject)
使用cairngorm 對于整個事件的流程會比較的清晰。個人認為它的整個流程很符合人類的思維方式。但是在實際開發中卻感覺 每當添加一個事件的時候，就要去寫event command delegate，事件一多就會感覺重復寫這些東西很煩。這時候就開始考慮更換一下框架，于是在頭的指導下去看了pureMvc框架。
學了兩天后，就深深喜歡上pureMvc了，哈哈！
顧名思義。pureMvc 就是純的mvc框架，許多人都錯誤地把PureMVC誤認為它是一個Flash的MVC框架或者是Flex的MVC框架。既然它是一個純框架，那么，它就不僅僅是支持某種特定 的語言，它的設計是與語言無關的。它支持了好多種常用的編程語言。
pureMvc的層次結構比cairngorm清晰的多，嚴格的MVC三層結構。
1、Model保存對Proxy對象的引用，Proxy負責操作數據模型，與遠程服務通信存取數據。
2、View保存對Mediator對象的引用。由Mediator對象來操作具體的視圖組件（View Component，例如Flex的DataGrid組件），包括：添加事件監聽器，發送或接收Notification ，直接改變視圖組件的狀態。
3、Controller保存所有Command的映射。Command可以獲取Proxy對象并與之交互，通過發送Notification來執行其他的Command。
pureMvc采用了“觀察者模式”（被觀察者是不關心觀察者是誰的），通過消息機制，來維持command 與 mediator的關系，將它們之間的耦合度降到最低。notification機制也是我最喜歡pureMvc的一個方面。
]]>
//輸出文件流
response.setContentType("application/octet-stream;charset=ISO8859-1");
String agent = request.getHeader("USER-AGENT");
if (null != agent && -1 != agent.indexOf("MSIE")){
response.setHeader("Content-Disposition","attachment;" + "filename=" + URLEncoder.encode( file.getName() , "UTF8"));
}
else if (null != agent && -1 != agent.indexOf("Mozilla")){
response.setHeader("Content-Disposition","attachment;" + "filename=" + new String(file.getName().getBytes("UTF-8"),"ISO8859-1"));
}
else {
response.setHeader("Content-Disposition","attachment;filename=" + file.getName() );
}
java.io.FileInputStream fr = new java.io.FileInputStream(fpath);
java.io.InputStreamReader is = new java.io.InputStreamReader(fr,"ISO8859-1");
java.io.BufferedReader br=new java.io.BufferedReader(is);
out = response.getOutputStream();
int i = 0;
while((i= br.read()) != -1){
out.write(i);
}
]]>
<s:set name="maxRowIndex" value="%{formInfo.maxRowIndex}"/>
for 循環
<s:bean name="org.apache.struts2.util.Counter" id="counter">
<s:param name="first" value="0" />
<s:param name="last" value="#maxRowIndex" />
<s:iterator>
</s:iterator>
</s:bean>
迭代<s:iterator>用于將List、Map、ArrayList等集合進行循環遍歷
<s:iterator value="#rowList">
</s:iterator>
if語句
<s:if test="#rowList==null">
</s:if>
生成html代碼
<s:property value="%{formInfo.jsCode}" escape="false"/>
escape="false" 不進行轉義
]]>
public int compare(DynamicFormField f1, DynamicFormField f2) {
if(f1.getRowIndex()!=f2.getRowIndex()){
return f1.getRowIndex()-f2.getRowIndex();
}else if(f1.getColIndex()!=f2.getColIndex()){
return f1.getColIndex()-f2.getColIndex();
}else{
return (int) (f1.getId() - f2.getId());
}
}
};
Collections.sort(fieldList, comparator);
return fieldList;
}
這是工作中 使用過的一個例子。
對fieldList中DynamicFormField對象 先按其rowIndex排序后按colIndex排序
]]>
]]>