2008年12月27日 星期六

[Interview] Infopower 英丰寶 面試經驗分享2

經過上次面試後,大約過了4天人資小姐又打電話來。帶著不安的心情我接起了電話,(內心OS:該不會要被發卡了吧!),哈!運氣很好的,是第二次面試!很興奮的約好了時間再去英丰寶大戰一場!

不過這次的面試不是很順遂,因為第一次約的時間,眼看自己準備要出發去,結果人資小姐又打電話來說:主管臨時有會議,所以要改時間!哇勒XD,主管是有沒有這麼忙阿!好吧,那就在換時間囉~

第二次面試前的五個小時,人資又打電話來,不過我沒有接到!心理一陣涼意,該不會是有要改時間吧!這該不會是要考驗一個人耐心的兵法吧~再度帶著不安的心情回撥電話,結果人資卻跟我說:沒有啦!只是要確認你下午會來喔!哇靠~差點沒嚇死我 囧

到了英丰寶,還是被請到上次面試的那間會議室,人資就說:總經理在開會,請你在多等十分鐘喔!等等~我有沒有聽錯!這次是總經理喔~天阿!大咖的出現了,等等還有更猛的~

這一等就是30分鐘,原來人資說的話要乘上3倍(開玩笑的!)

總經理一進來後,先確認完名字無誤後就先說了一句話:以往能夠到我這一關的人不超過 10 個!這句話有兩個含意:第一,這是誇獎(科);第二,我是最後決定你去留的人!我慌了~果然是來頭不小的魔王~

一開始就先問,為何要選擇研發替代役啦!然後你跟別人有怎樣不一樣的地方,也就是要你 promote 一下自己等等的

之後就談談論文的東西,還問我前瞻性~偏偏我們實驗室做的東西還很新,未來的發展要看市場,最後我就把老闆曾說過的 semantic web 願景大略的說給了經理聽!

接下來就是問問家庭背景啦!父母親的工作、從父母身上學到的東西等等~然後就是一連串的說英丰寶跟外面的軟體公司有些啥不一樣的~話中還偷偷嗆新店的 ERP 公司(我想大家應該都很清楚)~

然後就是換我打擊啦~不過我只有問一個問題(原本準備了兩個,因為經理的氣勢實在是太強了!第二問題我就忘了問):公司員工的年資!經理說:核心的研發人員最久的有 9 年,最年輕當然有不到一年,公司人員的流動不太大,不知道是真是假,知情的人分享一下吧~

這場面試就這樣結束了!好快,才 30 分鐘左右,感覺很不錯,只是經理會從頭盯著你的眼睛看,似乎是想要從說話中找出你有沒有在說謊~問的問題都會層層的過濾你是否是公司要找的人!總之,我覺得壓力很大~

後記~回家後上網查了一下,這位所謂的總經理就是公司了創辦人阿~天阿~遇到最終大魔王了!

以上,分享給想要去英丰寶面的人~

2008年12月24日 星期三

[Agile Method] 少量而高品質的Document

今天 meeting 時,老闆剛好有提到 agile method 的 document 觀念,我就順便問了一下上次去英丰寶面試時被問到的其中一個問題:當我們在開發專案時,我們要怎樣知道哪些文件是該寫?當時我回答的內容是:在專案開發時,如果認為某些文件是需要撰寫的,那就去寫,如果有哪些文件是過時或是無法在繼續維護與同步的話,就要大膽的刪除!不過,在 agile method 中強調,最重要的文件其實就是 pseudocode,也就是程式中的註解。因為 pseudocode 才是 developer 當初寫程式時的思維!這點很重要,雖然原先的 agile method 中並沒有硬性規定,但是我在實驗室中開發 ITRI 計畫的實際經驗來看,pseudocode 的確很重要,因為使用者常常會更改系統的需求,如果當初有寫好 pseudocode,修改程式所花費的時間就會大幅的降低!這點我很肯定!

講了這麼多,老闆今天給我的回應是:當我們在開發專案時,無論開發系統是否有特定的使用者,都需要先從 scenario 下手,也就是先將系統的使用情境撰寫出來,這是所有文件的起頭!因為有了 scenario 之後,我們就可以根據 scenario 撰寫出 use cases(跟 use case diagram 一點關係都沒有!),這些 use case 是將 scenario 中所描述的功能以程式的角度去描述!也就是定好 input, output 與呼叫的關係。接下來就是根據 use case 寫出 class interface ,這裡的 class interface 是指撰寫出空的 class 架構與 method signature(含 parameters),再來就是根據 use case 中的輸入輸出撰寫 test code,完成了 test code 之後就是寫 class 中每個 method 的 pseudocode,最後才是補上 source code。

上面所說得是基本的文件,如果開發團隊之間的溝通能力較弱的話,可以就得視團隊情況去撰寫需要的文件,如:class diagram 等。但是如果團隊溝通的能力較強,也就是團隊成員之間都清楚這個系統的詳細資訊的話,文件能不多寫就不要浪費力氣,因為修改使用者要變更的需求是需要花更多的力氣!

但是如果使用者要求一些超越基本文件的範圍,那當然還是要撰寫,畢竟使用者是最大的!給錢的永遠是老大~

今天還有問到 UML 圖到底要不要去寫的問題。老闆的想法是:完全不用!因為系統開發完之後,我們可以透過逆向工程工具幫助我們由完成的 code 去產生 class 與 sequence diagram,當然,系統完成後我們也不必多花時間來作逆向工程來產生 UML 圖,而是有需要再去作~畢竟,少量的文件是 agile method 的想法,但是要以高品質為前提!

對於文件的觀念,agile method 與 CMMI 完全是站在不同立場上去思考的!我個人是比較贊成 agile method 的看法,這並不是因為我們實驗室是採用 agile method 的關係,我本身也有上過 CMMI 的課程,雖然不是很專精,不過看到 CMMI 需要撰寫很多的文件就很令人頭疼!在台灣,很多公司為了獲得 CMMI 的資格,文件都是有目的在寫的!老實說,身為工程師我想沒有人是喜歡寫文件的,畢竟寫文件是一種吃力不討好的工作。但是如果文件與系統沒有同步,一百頁的文件也形同浪費硬碟空間的垃圾~文件太多,同步所花費的時間與力氣就越多,所以要精簡文件的數量。

以上是小弟個人淺見~希望有興趣的人可以多多討論!

2008年12月20日 星期六

[Struts2] 在Eclipse中開發Struts2 web project

首先,以下我所使用的eclipse版本為3.3。

1. 在eclipse的command line中我們按下[File]->[New]->[Other…],如圖一

clip_image002

圖一 [Other…]

2. 按下other後會出現如圖二的畫面後,在web之下選擇Dynamic Web Project。

clip_image004

圖二 Dynamic Web Project

3. 按下 Next 之後,出現圖三的畫面,我們就輸入我們所期望的project name。剩下的設定我們就採用預設值。

clip_image006

圖三 New Dynamic Web Project

4. 接著就按下Finish。我們在Package Explore中的看到Eclipse幫我們建立的樹狀結構如圖四。

clip_image008

圖四 Struts2 web project樹狀結構

5. 接著,我們就到 Struts2 官方網站下載最新的Struts2程式。將下載的檔案作解壓縮後,我們在資料夾中會有apps的資料夾,如圖五。

clip_image010

圖五 Struts2官方檔案解壓縮後

6. 在apps資料夾中我們將struts2-blank.war中的/WEB-INF/lib底下的所有檔案複製到我們剛剛所建立的web project中相對應的位置,也就是/WEB-INF/lib之下。

7. 接著我們就對我們的web project進行refresh,對project按下滑鼠右鍵,在選單中選擇Refresh,如圖六。

clip_image012

圖六 更新project

8. 再來就是要讓我們的web server可以在啟動我們的web app時啟動Struts2的filter。所以我們要在/WEB-INF/web.xml中加入:

<!-- Struts 2 default filter and filter mapping -->
<filter>
<filter-name>struts2</filter-name>
<filter-class>
org.apache.struts2.dispatcher.FilterDispatcher
</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>


9. 所以完成後的web.xml檔案內容會如圖七。關於web.xml的相關設定請參考tomcat的說明。



clip_image014



圖七 web.xml



10. 再來我們還需要一個struts.xml檔案,這個檔案是Struts2的主要設定檔,在我們的web project中的src資料夾按下右鍵選擇[New]->[Other…],出現的視窗如同圖二,選擇XML中的XML。然後將新增的檔名設定為struts.xml,這個檔名是不能隨意更改的,不然Struts2會讀取不到。struts.xml檔案內容我們就放入:



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
<struts>
</struts>


11. 這樣就完成初步的佈署了!為了之後要在開發上的方便,我們先將此web project為出成一個war檔案。對我們的project按下右鍵並選擇Export,如圖八。



clip_image016



圖八 匯出專案



12. 接著我們就將project匯出成WAR file,所以選擇Web之下的WAR file,如圖九。



clip_image018



圖九 WAR file



13. 按下Next後,我們要將檔案匯出到我們的目的地。所以設定Destination。指定好儲存位置後就按下Finish。這樣我們之後就可以利用匯入的方式使用了!

2008年12月13日 星期六

[Interview] Infopower 英丰寶 面試經驗分享

星期一收到人資寄信邀請我去面試,因為我有投這家公司的研發替代役!收到來信的我當然是超級興奮的!因為我還沒有正式的面試過~雖然接 case 前會有面試,不過那樣的面試對我來說並不算是真正的面試!

Infopower 英丰寶,公司負責開發一些 enterprise solution。自己點連結進去看一下吧~如果你有興趣。公司不大,資本額也算小的,有興趣的人就自己去查一下 104 的黃頁吧!

那天人資寄信給我時,有特別交代要準備投影片,內容還有規定~大致上就是如何將自己所學的東西貢獻給公司以及專業技術方面的經驗等!當然,我也是依照這樣的方式去準備~面試前自己可是超級緊張的~

一進到公司裡,就看到有些人站著在聊天喝咖啡,感覺氣氛非常融洽!進到了會議室後,總機小姐就拿了一份考卷給我,「時間三十分鐘,答案紙下方可以做計算」,這跟我在網路上查到的不一樣耶~大家都好像只有面試而已,沒有考試耶XD 該不會是我程度太差~不過我覺得考卷很簡單,都是考一些 JAVA 的程式題,細心度與觀念一定要夠,這樣應該就 OK 了!

交卷後,另一位感覺年輕的工程師進來跟我面談,結果,他帶的筆電沒有裝 office,囧。所以他就去載了個 viewer 來使用。

在下載檔案之餘,他就先希望我廣泛的描述一下我曾經修過哪些課是印象深刻的?說說自己的感想。我們就以很輕鬆的對話開始了這場 30 分鐘的面試。

開啟簡報後,我原本想要依照我的方式去報告,不料!對於我所學的東西,有一樣是他沒有興趣的,所以他就說:抱歉喔!今天不是要來上XX技術的課程!你這部份就精簡的描述一下吧!哎呀~完全打亂了我的節奏!還好我還可以接受,接下來的一張投影片,他就非常有興趣。他說:好!這張你不用講,我直接問你問題好了!雖然接下來的問題我回答的不盡理想,不過他也沒有顯露出"你真的在亂蓋"的表情,所以還是OK。

最後我就分享一下我接 case 的經驗,他會提出一些經驗上得問題來考考我!

進入最後一張投影片後,他就開始一連串的提出技術性的問題!有一題我其實只有回答一半:以你撰寫 JAVA 五年的經驗來說,你覺得 JAVA 的優缺點在哪裡?哇!這題好難,我只有回答他關於 JAVA 的好處,壞處我就說其實我沒有仔細想過~感覺這裡就扣好多分喔!><

另外就是寫程式遇到最難解的 bug 是哪個?Struts and Struts2 的差別?你以後想要做什麼?大概就是這些問題~能回答的我就盡量回答囉!

最後他就問問我對於公司有沒有問題阿?我就問了他們幾點上下班。他回答完後就反問我:你為什麼會 care 公司的上下班時間?我就跟他說,因為我也希望我有自己的時間!(心想:爆了) 結果他說:這跟公司當初成立的理念相符合,操爆員工是不對的!

總結,今天的面試其實很愉快~面試的工程師人很好,很仔細的聽我的回答~不會硬要追著我回答錯的部份窮追猛打!也很廣泛的說明了公司的特色與研發替代役在公司的角色等等。這家公司雖然小,不過工作氣氛感覺很不錯!重點是他們家所有產品的核心技術都是自己研發的!也就是自己有在研發產品的關鍵零組件,公司的前景是否光明?我也不知道~

2008年12月6日 星期六

[Discussion] Why has the Web become the Default Development Platform?

不知在哪一天,我得知了 InfoQ 這網站,我覺得這個網站的內容很棒,也很先進,因為每天會有許許多多的人在上面分享自己的看法,有點類似討論區,不過又有點不一樣,我也說不上來!在這網站中我知道了很多最新資訊!

Why has the Web become the Default Development Platform?是我最近看到的一篇文章,我就有感而發一下吧~

文章中提到 DWR 的創始者 Joe Walker,曾經提出一項看法:Web 已經成為系統開法者首選的開發平台。這裡所謂的開發平台不是指 JAVA 或 C 的開發環境,而是系統的佈署與介面的顯示環境。

Joe 提出這樣的看法有他的理由,Web 平台與生俱有的特性:1) 系統容易佈署、2) 簡單的 UI 介面開發、3) 單純的 HTML 語法與 4) 開放性的平台架構,這些都讓 Web 一躍而晉身成為系統開發者的首選平台。

Google 工程部門的副總,Jeff Huber 也提出同樣的說法:(內容我無法完全聽懂XD)

Jeff Huber 提到:如果你還是在思考採用哪種平台會比較好,你就還活在遠古時代的思維。因為 Web 已經勝出了!Web 就是未來的開發平台。

讓我們延續上面 Joe 所提到的四點特行來探討。

1. 系統容易佈署。系統的佈署曾經是開發者頭疼的問題之一,因為機器上 OS 的異質性,讓 programmer 經常要為了 portable 問題而費盡心思,不過,Web 平台就是可以讓 programmer 不必在費心於這樣的問題。因為 Web 的平台可以達到 zero installation。就像我們透過 J2EE 開發 Web 技術一樣,所有的 WAR 檔都交給 web server(如:Jakarta Tomcat) 來幫我們佈署,我們只要將檔案丟給 web server,他就會幫我們處理一切的佈署事宜。甚至,我們無須要求 client 端安裝任何的軟體,因為 OS 都具備有 browser 軟體,client 端可以不用有壓力的使用 web 平台上的東西。

2. 簡單的 UI 介面開發。HTML 語法已經行之有年,並且經過了許許多多的研究幫忙提供與開發更好用更方便的標準與技術,例如:DHTML、CSS、Javascript或是近年來走紅的 AJAX 等。這都讓開發者可以簡單的基於這些標準或技術之上來達到系統的目的。甚至,在 J2EE 應用裡,有許許多多的 OpenSource 也提供了更快速更方便與更直覺的開發框架,如:Velocity 或 FreeMarker 等介面的框架。

3. 單純的 HTML 語法。如同上述,HTML 原本的用途在於簡單的將資料能夠在網路上顯示,所以提供的語法採用 Markup Language 來表示,這不僅僅讓使用者可以快速上手,也是 machine readable。

4. 開放性的平台架構。Web 最基本的就是 HTTP Protocol,這也是 Internet 中使用最頻繁的 protocol 之一。所以只要系統佈署後,就可以讓系統在網路上被搜尋到與使用到。

除了這四點之外,我個人認為 Web 平台還有一項優勢:Web 平台尚以經有許多的 framework 讓系統的架構可以更容易開發與維護。在 J2EE 應用中有許多的 framework,如:Struts, WebWork, Spring MVC 等,都致力於讓 Web 系統符合 MVC design pattern(也就是 separate of concern 的概念),如果開發者採用 Web 作為系統的開發平台,那就可以更進一步的選用 OpenSource 的 MVC framework,這樣讓系統更具有 robust 與 reliability。而 MVC 架構在傳統的 Application 中並沒有現成的 framework 可以使用,這導致系統開發者要自己處理 MVC 中很 detail 的事項,或者就是要自己開發 MVC framework。

以後小弟在各網站之間有看到哪些好玩的訊息,在分享給大家吧~

如果您有任何想法或指教,您可以留言或寫 mail 來一起討論與切磋喔~

2008年12月4日 星期四

[DWR] Direct Web Remoting - Using Object

上次有提到簡單的使用 DWR 了! 不過上次的範例是採用 String 作為 server 端服務的回傳值,那如果我們要回傳的結果不只是 String 而是物件的話,DWR 能幫我們處理嗎?

這問題,DWR 當然都幫我們解決了! 而且我們要撰寫這樣的 code 並不難,跟我們撰寫 String 回傳值有 99% 相似! 這就是 DWR 的功力啦~

首先,我們改寫上次的 DWRServer class,增加新的 method:

public class DWRServer {
    public String sayHello(String name) {
        return "Hello! "+name;
    }
    public HelloObject sayHelloObject(String name) {
        HelloObject hello = new HelloObject();
        hello.setYourName(name);
        hello.setMyName("Silver8250");
        return hello;
    }
}
class HelloObject {
    private String yourName;
    private String myName;
    //setter and getter methods
}

這是我們增加一個 sayHelloObject() method 這個 method 會回傳一個 HelloObject (我們定義在下方) 的物件。HelloObject 中儲存前端使用者傳入的 name 與作者我的 name,裡面的 methods 都是針對 yourName 與 myName 變數的 getter 與 setter methods,在此就不列出(不懂? 趕快去了解一下 JavaBean 吧!)。

後端程式寫完後,依照慣例就是設定我們的 dwr.xml 檔案:

<dwr>
    <allow>
        <create javascript="myHelloServer" creator="new">
            <param name="class" value="DWRServer"></param>
        </create>
        <convert converter="bean" match="HelloObject"></convert>
    </allow>
</dwr>

在這裡我們並不增加新的 create tag,因為我們並沒有增加新的 server 端 class,我們只是在既有的 class 上新增加 method,不過要注意的是因為我們的 method 回傳的是一個 JavaBean(也就是 HelloObject),所以我們要在 dwr.xml 告知 DWR 這件事。所以我們使用 <convert> tag,並且設定 converter attribute 的值為 bean,這樣 DWR 就知道我們是用 JavaBean,而且 match 的值要放 HelloObject class 的所在位置(當然要包含 package)。這完成後,前端就可以使用這樣的 JavaBean 來取值囉!

前端的程式我們依舊要加入:

<script src='/MyProject/dwr/interface/myHelloServer.js'></script>

<script src='/MyProject/dwr/engine.js'></script>

然後我們在前端的 javascript 更改為:

function callSayHello(myName) {
    myHelloServer.sayHelloObject(myName, showResult);
}
function showResult(result) {
    document.getElementById("resultTextMyName").value = result.myName;
    document.getElementById("resultTextYourName").value = result.yourName;
}

原先的呼叫就更改為 sayHelloObject,因為 parameter 沒有差異,所以不變。但是神奇的是在 showResult function,我們一樣放 result 作為 argument,不過裡面的呼叫就改了,因為現在的 result 不是 String 而是我們的 HelloObject 物件,我們要取值,就直接呼叫 result.myName,就可以。DWR 會自動幫我們去到 server 呼叫 result.getMyName() 然後回傳! 神奇吧~

其實,用物件作為回傳值其實跟用 primary type 作回傳值是類似的,差別在於回傳的結果在前端的頁面可以有像物件般的曲裡面的 fields 的功能!

我的 DWR 目前也只有 survey 到此,往後有機會再深入的 survey,日後在分享給大家~

[DWR] Direct Web Remoting

最近在中大電算中心接的 CASE 中,因為是一個 web platform 的校務系統,又剛好加上 AJAX 的技術,後來 PM 希望可以將原先的 AJAX 改為使用 DWR framework,所以就 survey 了一下這個 framework。

大學時期,上過 Web 2.0 的課程,當初有聽過 DWR 這樣的 framework,只知道可以讓 Java programmer 很快速的開發 AJAX 上的應用,不過當初授課的教授建議我們不要去使用這樣的東西,原因我就忘記了!不過當初 DWR 的版本還是第一版的,可能有一些安全性的問題吧!不過現在已經演進到 DWR 2.0 版本了!

講了一堆無關緊要的東西~讓我們就趕快切入主題吧!

DWR 全名為 Direct Web Remoting,官方網站:http://directwebremoting.org/,由官網的標題就可以知道 DWR 目標在於讓 Java programmer 可以很容易很輕鬆的開發 AJAX 的應用。

DWR 所能夠做到 AJAX 範圍實在廣大,不過因為我只有簡單的使用,所以就將我 survey 到最基礎的技術分享一下吧!

首先,不用我說應該也知道,就是要先下載 DWR 的 JAR 檔案!從網站上的連結就可以取得最新的 dwr.jar 檔案。由於我所使用的 web framework 是 Struts 1,所以我們就將 dwr.jar 放置於 {web project} \ WEB-INF \ lib 之下。

接下來就是要設定一下專按下的 web.xml 檔案,讓 dwr framework 可以在我們開發的 web project 啟動時被抓到。所以我們在 web.xml 中加入:

<servlet>

  <servlet-name>dwr-invoker</servlet-name>

  <servlet-class>

    org.directwebremoting.servlet.DwrServlet

  </servlet-class>

</servlet>

<servlet-mapping>

  <servlet-name>dwr-invoker</servlet-name>

  <url-pattern>/dwr/*</url-pattern>

</servlet-mapping>

更多的 web.xml 設定檔案請按我。設定完成後,我們還要建立一個 dwr.xml 檔案,並放置於 WEB-INF\ 之下,dwr.xml 是設定我們在 server 端的服務與物件,讓前端可以呼叫後端服務的設定檔。在 DWR 2.0 中引進了 annotation的機制,讓我們可以不用撰寫 dwr.xml,有興趣的人可以自行去 survey 這部份!(跟 Struts2 好像~)

我們在 dwr.xml 中的第一行要先加入:

<!DOCTYPE dwr PUBLIC "-//GetAhead Limited//DTD Direct Web Remoting 2.0//EN" "http://directwebremoting.org/schema/dwr20.dtd">

這樣就可以讓 eclipse 幫我們檢查與產生輔助工具。

接著我們就可以先來撰寫一個 server 端的程式,我們可以很輕巧的建立一個 server 端,因為在 DWR 之下我們並不需要 extends 或 implemented 任何的 class 或 interfaces。這樣我們在開發程式上並不會受到限制,也就是說,我們可以 reuse 過去的 code 等。

public class DWRServer{

    public String sayHello(String name) {

        return "Hello! "+name;

    }

}

這樣的 server 程式夠簡單吧!我還是遵照市面上書籍的慣用 startup example 來示範!

有了後端的程式後,我們當然就要先設定一下我們的 dwr.xml 檔案,這樣在前端的 javascript 才可以呼叫與使用。所以我們就在 dwr.xml 中寫入:

<dwr>

    <allow>

        <create javascript="myHelloServer" creator="new">

            <param name="class" value="DWRServer"></param>

        </create>

    </allow>

</dwr>

dwr.xml 中的 root node 就是 <dwr>,這沒有為什麼,因為就是 DTD 描述的規定。接下來我們就放置 <allow>,告知 DWR 有哪些 server 服務是可以讓前端存取的,與 <allow> 平行的 tags 還有 <init> 與 <signature>,我在這裡就不多加介紹,因為目前在我們的範例中並不會使用到,不過我想聰明的你應該可以大致上猜到這兩個 tags 的用途,因為這蠻直觀的!

再來,我們就要開始描述我們的後端 server 了,所以我們使用 <create> tag,從名稱上我們可以解釋為建立一個新的 server 端服務給前端使用,然後我們可以要指定一個名稱讓前端存取,這個名稱我們要撰寫在 allow tag 中的 javascript attribute 的值,就如同我所寫的 myHelloServer,這個名稱可以隨機取,不過每個 allow tag 彼此的 javascript attribute 的值不可以重複!然後我們要在 allow tag 中寫入 creator="new" 的 attribute 與 value,這應該就是告知 DWR 這是要建立服務的!

有了服務的名稱後,我們在要 allow tag 中 nested 一個 param tag,用來傳入一些參數給 DWR,必要的就是指定 name="class" 與 value 為我們撰寫 server 程式的名稱(要包含 package,我們在這裡使用 default package,所以沒有寫入),這樣 DWR 才可以知道這服務實際上是要呼叫哪個 class。當然,我們可以傳入的 param tag 還可以有其他的設定值。

後端完成後,那我們就要走到前端囉!

前端的撰寫其實也是很簡單,因為我們可以不用自己處理 AJAX 在不同瀏覽器之間的差異性,DWR 都會幫我們去完成這樣複雜且無趣的工作!

回到正題,撰寫前端的 JSP 頁面時,我們必須先在前面加入兩個 javascript 的 references:

<script src='/MyProject/dwr/interface/myHelloServer.js'></script>

<script src='/MyProject/dwr/engine.js'></script>

首先是第一個,這是要告之前端的頁面說我們剛剛設定的服務要匯入,你一定會感到很神奇,我們根本就沒有撰寫 myHelloServer.js 這檔案阿!不過這就是 DWR 會自動去幫你虛擬的產生~至於第二個就比較簡單,因為這是 DWR 必要的一些資源,所以一定要加入的。

接下來就是前端的重頭戲囉~我們要如何在前端呼叫後端的服務呢?相信我,看完接下來的範例後,你一定會驚嘆不已!這真是太神奇了~

在前端我們撰寫以下的 javascript:

function callSayHello(myName) {

    myHelloServer.sayHello(myName, showResult);

}

function showResult(result) {

    document.getElementById("resultText").value = result;

}

第一個 function 是讓我們呼叫 server 端的,我們在裡面可以直接使用 myHelloServer 來當作一個物件,然後呼叫 sayHello,並將參數傳入!有沒有很像在寫 server 端的 JAVA 程式呢?超直觀的~那你一定會問,我們的 sayHello() method 只需要一個 parameter 阿?第二個參數目的?第二個參數是要讓 DWR 在執行完結果後可以 call back 的 function,這樣當我們的呼叫完成後,前端頁面就會呼叫 showResult function。

第二個 function 就是負責將 server 回傳的結果顯示,此 function 的 argument result 是必要的!這是為了接收 server 端的結果之用。我們將 server 回傳的結果簡單的顯示某個 HTML element 上!

簡單的範例就此結束了!神奇吧~我第一次寫完後也覺得超神奇的!

Server 端的回傳不僅僅可以是一個 primary type 或 String,我們也可以放置物件作為回傳參數!這部份,就待續吧~