回來轉眼上了一星期班了，忙的屁滾尿流
一年前的系統要增加兩個大功能，200多個報表要挨個修改，報表校驗的頁面效果客戶又提出了新建議，一個字 改

從昨天晚上開始搗鼓到現在終于解決了一個問題，心情好了些，上來寫寫，哈哈

這兩天用了baidu 百度空間中的彈出窗口js，感覺不錯，很強大，很好很簡單的解決了好幾個問題，界面友好度以及美化也好多了，以前都是硬邦邦window.open();

有興趣的朋友搜索"百度 popup"就好了，已經有人給出了注釋，強大。

最有意思的是用javascript獲取和設置style

DOM標準引入了覆蓋樣式表的概念，當我們用document.getElementById("id").style.backgroundColor 獲取樣式時 獲取的只是id中style屬性中設置的背景色，如果id中的style屬性中沒有設置background-color那么就會返回空，也就是說如果id用class屬性引用了一個外部樣式表，在這個外部樣式表中設置的背景色，那么不好意思document.getElementById("id").style.backgroundColor 這種寫法不好使，如果要獲取外部樣式表中的設置，需要用到window對象的getComputedStyle()方法，代碼這樣寫window.getComputedStyle(id,null).backgroundColor
但是兼容問題又來了，這么寫在firefox中好使，但在IE中不好使
兩者兼容的方式寫成
window.getComputedStyle?window.getComputedStyle(id,null).backgroundColor:id.currentStyle["backgroundColor"];
如果是獲取背景色，這種方法在firefox和IE中的返回值還是不一樣的，IE中是返回"#ffff99"樣子的，而firefox中返回"rgb(238, 44, 34) "
值得注意的是：window.getComputedStyle(id,null)這種方式不能設置樣式，只能獲取，要設置還得寫成類似這樣id.style.background="#EE2C21";

參考：
JavaScript權威指南
http://bokee.shinylife.net/blog/article.asp?id=817
http://book.csdn.net/bookfiles/679/10067921329.shtml

感覺普元的報表有點水晶的味道，弄了個分組報表，又建數據源又建數據集有設行分組，列分組的，趕緊挺麻煩，沒有用潤乾好使，雖然潤乾工作量也挺大

看來老板要貼了心上普元了，接下來可能要實戰了，不知道啥樣，現在有兩點困難;

1\、普元報的錯誤，無從下手，不知道哪出的毛病，比如有時在展現層的毛病，而在邏輯處理層報錯，摸不著頭腦啊。

2、普元的構件不熟悉，據說有1000多個構件，不像java api一樣按照功能分的包，它是按層分的包，業務邏輯層構件、運算層構件、展現層構件。要實現一個功能怎么能知道構件包里有沒有現成的，恐怕這只能慢慢熟悉那些構件庫了

3、覺得普元的報表系統不怎么樣，至少沒有什么讓人耳目一新的，工作流系統還挺強，對工作流不熟悉，不敢說什么，然后就是可維護性，可擴展性，可能一直是自己寫代碼的，看不見代碼總覺得不踏實最然功能實現了并以更迅速的

4、聽頭兒說這是未來軟件開發的趨勢，聽得我直郁悶，未來開發就是這么托構件然后用連線一拉基本完事兒了嗎？！得，要不我還是轉行做小買賣去吧，嗚嗚，總的來說，覺得這種模式對程序員個人的發展沒多大好處，核心代碼都被封裝好了，不知道什么是類，對象，方法，面向對象，也能輕而易舉做軟件工程師了，呵呵，工程師以后不值錢嘍。

自己的一點感覺，胡侃一通，不知道合不合乎邏輯，在前面的blog里有朋友留言說"千萬別被普元忽悠了"，哈哈，不知道那位兄弟的理由是什么，想多聽聽大家的意見，望廣留言，多謝多謝多謝！！！

<root>

<data>

<myEntity>

<myField1>1234</myField1>

<myField2>This is demo</myField2>

</myEntity>

</data>

</root>

例子2：EntityList的格式為

<root>

<data>

<list length=2>

<myEntity name="test1">

<myField1>1234</myField1>

<myField2>This is demo</myField2>

</myEntity>

<myEntity name="test2">

<myField1>2345</myField1>

<myField2>This is demo</myField2>

</myEntity>

<list>

</data>

</root>

通過Xpath來訪問數據，比如

/root/data /myEntity將訪問到例子1中的<myEntity>實體

/root/data/myEntity/ myField1 將訪問到例子1中的myField1，結果為1234

/root/data/list/myEntity[@name="test1"]將訪問例子2中的<myEntity name="test1"> 實體

/root/data/list/myEntity[@name="test1"]/myField1將訪問例子2中的myField1，值為1234

昨天臨時以前的項目要改寫東西，聽的斷斷續續

還是一些關于工作流的知識，只是更加復雜一下，跟著文檔一個勁兒的復制黏貼

也不知道所以然

據說下午還要考試，暈

感覺看不到親切的java代碼很不爽，呵呵

然后練習自定義運算邏輯，這下自己寫類了呵呵，eos能夠由向導自動生成類和方法體，就像Myeclipse中新建struts的action一樣，發現eos的方法都是靜態的，都是返回一個int整型值，參數列表也都是Document doc, BizContext param，看起來只有方法名可以自定義了，呵呵！

之前說過普元這套東西都是用xml格式傳遞參數的，這里就是從param中獲取xml，然后拆解每個要用到的節點，來獲取傳入的參數，然后經過處理后把返回值再放到xml節點中，好費勁。

然后是handler，為了靈活的加入新的處理，可以在一個業務邏輯的前后加入多個handler,跟一般的過濾器寫法沒什么差別。

然后是jsp Tag自定義，也是繼承了javax.servlet.jsp.tagext.TagSupport，沒有普元的東西

再然后是復雜查詢，多表查詢，他是創建一個查詢實體，就是視圖啦

一天下來對普元EOS了解的多了些，它以方法為單位作為構成構件，以達到重用的目的，各個層之間以xml格式作為聯系，開發人員基本上已圖形化開發，不接觸底層技術，給程序員的門檻降低了（大學生就業更難了呵呵），開發系統開始工業化，把零件裝起來，螺絲擰上就OK了

可能經歷實際開發了，會有多一些不一樣的感觸吧

還是沒鬧明白難道這就是所謂SOA嗎？？？

公司要購進普元的EOS開發工具，組織為期5天的培訓

為了今天的培訓我把我的筆記本系統都重裝了，折騰了半天裝數據庫，裝EOS，裝EOS補丁，不知道干嘛不做一個集成了補丁的安裝包

安裝過程中要配置數據庫，要初始化數據庫，會向數據庫中自動建好多表，然后安裝成功后可以在服務控制臺管理。

首先做了個HelloWorld

界面就是這樣的

首先新建一個構件包(面向構件的開發嘛)，每個構建包下有頁面構件page，展現邏輯構件pr，業務邏輯構件biz，數據邏輯構件data等等。

我的理解就是每個構件就相當于分層架構中的一層，page就是jsp頁面，pr是Struts的action，biz是spring的bean,data是hibernate的映射，普元在這之上又進行了封裝，以前我們在各個層之間傳遞數據通常由一個DTO數據傳遞對象，而普元在各個層用xml來傳遞，普元把普遍通用的實現邏輯處理都封裝成了構件，我們只要調用構件就行了。

       之后又來了復雜點有刺激的，通過向導實現對一個單表的增刪改查，向導跟vs.net中的那個數據連接，數據適配器拖到頁面上選擇表，選擇字段，就自動生成了增刪改查，只是vs.net中可以看到生成的C#的代碼，而普元生成的只是一堆xml。

原來一天未必能完成的事，現在十分鐘做完，能傻瓜的都傻瓜了，真的也要下崗了。

哦，對了，這些和SOA怎么聯系上呢？

    <url-pattern>/test/list.do</url-pattern>

② 目錄匹配

    <url-pattern>/test/*</url-pattern>

③ 擴展名匹配

    <url-pattern>*.do</url-pattern>

servlet-mapping的重要規則：

☆ 容器會首先查找完全匹配，如果找不到，再查找目錄匹配，如果也找不到，就查找擴展名匹配。

☆ 如果一個請求匹配多個“目錄匹配”，容器會選擇最長的匹配。