hot的學習筆記

     摘要: 開源報表工具現狀
目前較為知名的開源報表工具有：
1、 JasperReports 一個優秀的Java  閱讀全文

    快下班的時候，收到小頭的關于Reset Css的一封郵件，看了一下才發現，哎呀！原來css還有這么玩的。
2004年，Tantek被不同瀏覽器下默認樣式的差異給搞煩了，于是寫了一個undohtml.css，這也就誕生了世界上第一份reset.css。
    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方案:
  
    哎，真是收獲良多啊！

    前些日子西安項目中的任務日志，以及最近參與工作流動態表單開發中都使用到了spring的aop。所以，自己簡單的進行了一下總結，也算是對前一段時間工作的一個總結吧。

 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的配置方式有許多種，這只是其中一種

 

   下面是 攔截器oaTaskInstanceLogOper類，采用的是環繞攔截的方式。

    前一段時間，曾經做過一點flex的開發工作，最初使用的是cairngorm，后來研究了一下 pureMvc，并進行了部分改造。
由于只是初步涉足flex領域，所以只能提出一點自己的看法，并不具有說服力。
    cairngorm 前端的控件監聽用戶的行為，只是監聽，并不會做任何反應?？丶O聽以后調用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" 不進行轉義

private List sortFieldListByRowIndex(List fieldList){
  Comparator<DynamicFormField> comparator = new Comparator<DynamicFormField>(){
   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排序

新手上路?。∠Ｍ院罂梢愿蠹叶嘟涣鳎?/p>