回來轉(zhuǎn)眼上了一星期班了,忙的屁滾尿流
一年前的系統(tǒng)要增加兩個(gè)大功能,200多個(gè)報(bào)表要挨個(gè)修改,報(bào)表校驗(yàn)的頁(yè)面效果客戶又提出了新建議,一個(gè)字 改
從昨天晚上開始搗鼓到現(xiàn)在終于解決了一個(gè)問題,心情好了些,上來寫寫,哈哈
這兩天用了baidu 百度空間中的彈出窗口js,感覺不錯(cuò),很強(qiáng)大,很好很簡(jiǎn)單的解決了好幾個(gè)問題,界面友好度以及美化也好多了,以前都是硬邦邦window.open();
有興趣的朋友搜索"百度 popup"就好了,已經(jīng)有人給出了注釋,強(qiáng)大。
最有意思的是用javascript獲取和設(shè)置style
DOM標(biāo)準(zhǔn)引入了覆蓋樣式表的概念,當(dāng)我們用document.getElementById("id").style.backgroundColor 獲取樣式時(shí) 獲取的只是id中style屬性中設(shè)置的背景色,如果id中的style屬性中沒有設(shè)置background-color那么就會(huì)返回空,也就是說如果id用class屬性引用了一個(gè)外部樣式表,在這個(gè)外部樣式表中設(shè)置的背景色,那么不好意思document.getElementById("id").style.backgroundColor 這種寫法不好使,如果要獲取外部樣式表中的設(shè)置,需要用到window對(duì)象的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)這種方式不能設(shè)置樣式,只能獲取,要設(shè)置還得寫成類似這樣id.style.background="#EE2C21";
參考:
JavaScript權(quán)威指南
http://bokee.shinylife.net/blog/article.asp?id=817
http://book.csdn.net/bookfiles/679/10067921329.shtml
感覺普元的報(bào)表有點(diǎn)水晶的味道,弄了個(gè)分組報(bào)表,又建數(shù)據(jù)源又建數(shù)據(jù)集有設(shè)行分組,列分組的,趕緊挺麻煩,沒有用潤(rùn)乾好使,雖然潤(rùn)乾工作量也挺大
看來老板要貼了心上普元了,接下來可能要實(shí)戰(zhàn)了,不知道啥樣,現(xiàn)在有兩點(diǎn)困難;
1\、普元報(bào)的錯(cuò)誤,無從下手,不知道哪出的毛病,比如有時(shí)在展現(xiàn)層的毛病,而在邏輯處理層報(bào)錯(cuò),摸不著頭腦啊。
2、普元的構(gòu)件不熟悉,據(jù)說有1000多個(gè)構(gòu)件,不像java api一樣按照功能分的包,它是按層分的包,業(yè)務(wù)邏輯層構(gòu)件、運(yùn)算層構(gòu)件、展現(xiàn)層構(gòu)件。要實(shí)現(xiàn)一個(gè)功能怎么能知道構(gòu)件包里有沒有現(xiàn)成的,恐怕這只能慢慢熟悉那些構(gòu)件庫(kù)了
3、覺得普元的報(bào)表系統(tǒng)不怎么樣,至少?zèng)]有什么讓人耳目一新的,工作流系統(tǒng)還挺強(qiáng),對(duì)工作流不熟悉,不敢說什么,然后就是可維護(hù)性,可擴(kuò)展性,可能一直是自己寫代碼的,看不見代碼總覺得不踏實(shí)最然功能實(shí)現(xiàn)了并以更迅速的
4、聽頭兒說這是未來軟件開發(fā)的趨勢(shì),聽得我直郁悶,未來開發(fā)就是這么托構(gòu)件然后用連線一拉基本完事兒了嗎?!得,要不我還是轉(zhuǎn)行做小買賣去吧,嗚嗚,總的來說,覺得這種模式對(duì)程序員個(gè)人的發(fā)展沒多大好處,核心代碼都被封裝好了,不知道什么是類,對(duì)象,方法,面向?qū)ο螅材茌p而易舉做軟件工程師了,呵呵,工程師以后不值錢嘍。
自己的一點(diǎn)感覺,胡侃一通,不知道合不合乎邏輯,在前面的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來訪問數(shù)據(jù),比如
/root/data /myEntity將訪問到例子1中的<myEntity>實(shí)體
/root/data/myEntity/ myField1 將訪問到例子1中的myField1,結(jié)果為1234
/root/data/list/myEntity[@name="test1"]將訪問例子2中的<myEntity name="test1"> 實(shí)體
/root/data/list/myEntity[@name="test1"]/myField1將訪問例子2中的myField1,值為1234
昨天臨時(shí)以前的項(xiàng)目要改寫東西,聽的斷斷續(xù)續(xù)
還是一些關(guān)于工作流的知識(shí),只是更加復(fù)雜一下,跟著文檔一個(gè)勁兒的復(fù)制黏貼
也不知道所以然
據(jù)說下午還要考試,暈
感覺看不到親切的java代碼很不爽,呵呵
然后練習(xí)自定義運(yùn)算邏輯,這下自己寫類了呵呵,eos能夠由向?qū)ё詣?dòng)生成類和方法體,就像Myeclipse中新建struts的action一樣,發(fā)現(xiàn)eos的方法都是靜態(tài)的,都是返回一個(gè)int整型值,參數(shù)列表也都是Document doc, BizContext param,看起來只有方法名可以自定義了,呵呵!
之前說過普元這套東西都是用xml格式傳遞參數(shù)的,這里就是從param中獲取xml,然后拆解每個(gè)要用到的節(jié)點(diǎn),來獲取傳入的參數(shù),然后經(jīng)過處理后把返回值再放到xml節(jié)點(diǎn)中,好費(fèi)勁。
然后是handler,為了靈活的加入新的處理,可以在一個(gè)業(yè)務(wù)邏輯的前后加入多個(gè)handler,跟一般的過濾器寫法沒什么差別。
然后是jsp Tag自定義,也是繼承了javax.servlet.jsp.tagext.TagSupport,沒有普元的東西
再然后是復(fù)雜查詢,多表查詢,他是創(chuàng)建一個(gè)查詢實(shí)體,就是視圖啦
一天下來對(duì)普元EOS了解的多了些,它以方法為單位作為構(gòu)成構(gòu)件,以達(dá)到重用的目的,各個(gè)層之間以xml格式作為聯(lián)系,開發(fā)人員基本上已圖形化開發(fā),不接觸底層技術(shù),給程序員的門檻降低了(大學(xué)生就業(yè)更難了呵呵),開發(fā)系統(tǒng)開始工業(yè)化,把零件裝起來,螺絲擰上就OK了
可能經(jīng)歷實(shí)際開發(fā)了,會(huì)有多一些不一樣的感觸吧
還是沒鬧明白難道這就是所謂SOA嗎???
公司要購(gòu)進(jìn)普元的EOS開發(fā)工具,組織為期5天的培訓(xùn)
為了今天的培訓(xùn)我把我的筆記本系統(tǒng)都重裝了,折騰了半天裝數(shù)據(jù)庫(kù),裝EOS,裝EOS補(bǔ)丁,不知道干嘛不做一個(gè)集成了補(bǔ)丁的安裝包
安裝過程中要配置數(shù)據(jù)庫(kù),要初始化數(shù)據(jù)庫(kù),會(huì)向數(shù)據(jù)庫(kù)中自動(dòng)建好多表,然后安裝成功后可以在服務(wù)控制臺(tái)管理。
首先做了個(gè)HelloWorld
界面就是這樣的
首先新建一個(gè)構(gòu)件包(面向構(gòu)件的開發(fā)嘛),每個(gè)構(gòu)建包下有頁(yè)面構(gòu)件page,展現(xiàn)邏輯構(gòu)件pr,業(yè)務(wù)邏輯構(gòu)件biz,數(shù)據(jù)邏輯構(gòu)件data等等。
我的理解就是每個(gè)構(gòu)件就相當(dāng)于分層架構(gòu)中的一層,page就是jsp頁(yè)面,pr是Struts的action,biz是spring的bean,data是hibernate的映射,普元在這之上又進(jìn)行了封裝,以前我們?cè)诟鱾€(gè)層之間傳遞數(shù)據(jù)通常由一個(gè)DTO數(shù)據(jù)傳遞對(duì)象,而普元在各個(gè)層用xml來傳遞,普元把普遍通用的實(shí)現(xiàn)邏輯處理都封裝成了構(gòu)件,我們只要調(diào)用構(gòu)件就行了。
之后又來了復(fù)雜點(diǎn)有刺激的,通過向?qū)?shí)現(xiàn)對(duì)一個(gè)單表的增刪改查,向?qū)Ц?/span>vs.net中的那個(gè)數(shù)據(jù)連接,數(shù)據(jù)適配器拖到頁(yè)面上選擇表,選擇字段,就自動(dòng)生成了增刪改查,只是vs.net中可以看到生成的C#的代碼,而普元生成的只是一堆xml。
原來一天未必能完成的事,現(xiàn)在十分鐘做完,能傻瓜的都傻瓜了,真的也要下崗了。
哦,對(duì)了,這些和SOA怎么聯(lián)系上呢?
<url-pattern>/test/list.do</url-pattern>
② 目錄匹配
<url-pattern>/test/*</url-pattern>
③ 擴(kuò)展名匹配
<url-pattern>*.do</url-pattern>
servlet-mapping的重要規(guī)則:
☆ 容器會(huì)首先查找完全匹配,如果找不到,再查找目錄匹配,如果也找不到,就查找擴(kuò)展名匹配。
☆ 如果一個(gè)請(qǐng)求匹配多個(gè)“目錄匹配”,容器會(huì)選擇最長(zhǎng)的匹配。