無垠天際

在Web Dynpro中提供3種資料流機制[1]，只要適當地設定，可以不用寫程式就將畫面、中間層控制器(controller)到後端模型物件的資料自動化地、牢靠地綁在一起，使得不管前後端某一方有資料變動，變動部份都會自動地流動來保持一致性，使得前後端都能存取到同一份資料。 context 關鍵元件是 context，每個controller都有一份屬於自己的context，它扮演MVC架構中的M (model)，web dynpro的實做方式比較像是該controller的「資料空間」，它由node(資料節點）與attribute（資料屬性）組成，controller可以透過wdContext這個預先產生好的 shortcut variable（捷徑變數）去取得context的資料內容。 context中必須要建立node才可以儲存資料，一個node代表一個collection(集合物件)裡面仍可以含有node, attribute，node裡面的一份資料實體就是一個element，一個node可以有一個或多個element（這部份可以透過cardinality property設定），其結構就是該node所包含的結構。 data binding 此種機制可以將UI元件的資料跟context中的某個node或attribute綁定在一起，context中的改變會自動 更新到UI元件上，UI元件的改變也會自動寫入到綁定的context node(or attribute)中。通常UI元件所綁定的node（attribute)是由component controller對應過來的。 context mapping 每一個controller都有屬於自己的context(資料空間)如果要達到彼此共享資料，則要透過context mapping機制，一旦mapping設定好，則會在另一個context產生一個同樣的結構的node，兩邊的controller會存取到的是同一分資料，任何一邊的資料更動都會散佈到設定好mapping的node。 不過在web dynpro裡，只允許將custom controller or component controller的node對應到view controller去，不允許從view controller對應回來，主因是嚴格遵守MVC

特長： 清晰的MVC架構 自動化建立模型類別(model class) 透過3種data model機制(model binding, context mapping, data binding)可以很容易保持資料模組化與前後端一致性 利用context node機制抽象化、統一化對後端各種不同model的存取方式 各種重用性高、可設定的UI元件，只要拖拉即可快速建立畫面 UI元件可與office、Adobe flex作某種程度整合 各種工具類別提高開發效率(ex: Window Manager, Message Manager) 畫面可以重複使用在不同的client裝置（web browser, pocket pc, blackberry)，無須重新開發 缺點： 沒有提供使用者輸入驗證的架構（要自行實做） UI元件無法客製 必須使用NetWeaver server，是SAP獨有技術 必需要用NetWeaver Development Studio開發，雖然是基於eclipse的IDE，但是許多好用的功能與快速鍵都被改掉，反而較不好用 不易與其他third party framework整合，如Hibernate

在jdk1.5下使用StringBuffer，如果在同一行連續使用append StringBuffer sb = new StringBuffer(); sb.append("test").append("test2"); 有些IDE會出現以下compilation error訊息： The Type AbstractStringBuilder is not visible. 但如果分開寫就沒有這個error： <big><br />sb.append("test");<br />sb.append("test2");<br /></big> 原因有兩個 其一是，Java2SE5.0 開始有covariant return types這個新feature，意思大約是「可變回傳型態」，主要是讓子類別在覆寫(override)父類別的某個method時，回傳型態可以是父類別回傳型態的子類別。例如 <br />Parent class{<br /> Parent getObj(...){...}<br />}<br /><br />Child class extends Parent{<br /> Child getObj(...){<br /> ...<br /> return Child;<br /> }<br /> 其 二是1.5之後新增了AbstractStringBuilder為StringBuffer, StringBuilder的父類別，但他卻是private類別，甚至從javadoc上也看不到此類別，你只會看到StringBuffer, StringBuilder都繼承自Object。 所以，第一種寫法，StringBuffer append()可能被IDE compiler判定回傳AbstractStringBuilder然後又呼叫其append()，導致發生找不到 AbstractStringBuilder情形，這應該是IDE可以解決的問題，我聽說ecli

在執行專案過程中有些事件，就跟「你想通了嗎」[1]一書中提到的情景類似，不過當下卻沒有察覺，都是事後解決才發現問題的癥結。 案例一： 在系統即將完成的後期，客戶才表示，其中一項W功能要增加一個新的表單，當初只談好要作2個表單，每個表單其實是對應到他們現有 一項業務，客戶負責提需求的人忘了提出他們還有另一項業務是不同於前2項的，必需要作一個新表單來專門處理這項業務。如果幫客戶做，則延長開發時間，不合 成本，但若拒絕，則這個系統又少了一項執行重大業務的功能，客戶接受度降低。當然我方大可以不符合約的理由正當的拒絕，但似乎不夠圓融，雖然後來我方委婉 說明，希望客戶打消此念頭，但客戶仍持續提出要求，這似乎是個兩難個局面。 後來的解決方法是在兩個原有的表單加上一個可以自由輸入的欄位，這樣，原有2項表單便免強可以轉作第三項業務使用，算是兩方都滿意的解法。不過這方法一開始也沒想到，是跟客戶討論的時候，被提醒的。這件事， 問題的擁有者 是 客戶 ，並不是我，也就是問題並不是「要不要作第三個表單？」，而該是客戶心理想的：「怎樣才能讓系統幫我處理第三項業務？」如果這樣思考就能跳脫出先前作新表單的思維中。 案例二： 我們要接手前一家公司做好的系統，並對其作部份的修正，需求很明確，但在專案一開始我們對技術與對方的程式碼都不熟悉的狀況下，客戶基層主管R就要我們提 出每項功能的時程，因為距離預定上線的時間只剩一個月，我們彼此又是第一次合作，因此主管R希望我們儘早告訴他我們的schedule。不過在不熟悉對方 系統架構與程式碼的狀況時，實在是很難估計明確的時間。這是一個兩難局面，隨意給一個時程，恐怕造成我們自己未來難做事，不給時程，客戶又相當堅持。 這問題的解決仍然是因為跟客戶溝通的拉鋸過程中，他偶然提到的訊息，因為他要給系統的user、主管一個交代，因此才要我們提出明確時程，因為距上線只有 一個月，我們就答應在三個星期後完成，中間的時程，之後再提出，這樣才算達成共識。一開始問題好像是「怎麼估計出工作時程？」，但是如果換到問題的擁有 者，主管R身上時，問題變成「我怎麼跟主管、user報告，系統何時可以完成？」 雖然我們常常聽過「換個角度想」，但是要換到哪個角度，卻是個問題，以上兩個都是比較簡單的狀況，只要我們換到問題的