ที่ผมไปทำ workshop เรื่อง Tapestry
วันนี้ก็เลยยกตัวอย่างที่ทำ workshop ของ Tapestry
มาเปรียบเทียบกับ Seaside ที่ใช้ smalltalk เขียน
เรื่องด้วย Counter Component ก่อน
เริ่มที่ tapestry
การเขียน Tapestry Component ต้องใช้ 2 file
เป็น java class กับ Html template
public abstract class Counter extends BaseComponent {
@Persist
public abstract int getCount();
public abstract void setCount(int value);
public void increase() {
setCount(getCount() + 1);
}
public void decrease() {
setCount(getCount() - 1);
}
}
<div>
<h3><span jwcid="@Insert" value="ognl:count">0</span></h3>
<a href="#" jwcid="@DirectLink" listener="listener:increase">++</a>
<a href="#" jwcid="@DirectLink" listener="listener:decrease">--</a>
</div>
ฝั่งของ Seaside จะมีแค่ file เดียว
เพราะ Seaside ไม่ได้ใช้ template
(อันนี้เป็นประเด็นทางศาสนา ฝ่ายสนับสนุน
เชื่อว่า pure smalltalk มันงามแท้ๆ)
WAComponent subclass: #WACounter
instanceVariableNames: 'count'
classVariableNames: ''
poolDictionaries: ''
category: 'Seaside-Examples-Test'
initialize
super initialize.
self session registerObjectForBacktracking: self.
count := 0
count
^ count
decrease
count := count - 1
increase
count := count + 1
renderContentOn: html
html heading: count.
html anchor callback: [self increase]; text: '++'.
html space.
html anchor callback: [self decrease]; text: '--'
rendererClass
^ WARenderCanvas
ลองดูความสวยงาม(ที่เขาว่ากัน) ของการ render html ใน method renderContentOn:
ถ้าตัดประเด็นส่วน syntax ที่ไม่เหมือนกัน
กับ Technique การ implement ที่แตกต่างกันออกไป
ก็จะเห็นว่าทั้งสองฝ่ายมีแนวคิดไปในทำนองเดียวกัน นั่นคือ
- ประเด็นเรื่องการ maintain state บนฝั่ง server,
ที่ให้ framework เป็นคนจัดการให้เรา
ทำให้เรามุ่งไปที่ กับ business logic ได้เต็มที่ - การพยายามทำให้ event ที่เกิดที่ฝั่ง client กลืนเข้าเป็น
เนื้อเดียวกับ script ที่ฝั่ง server,
ซึ่งในแง่ของการร้อย event, ทางฝั่ง smalltalk ทำใด้เนียนกว่า
ลองดูการนำ component มาใช้งานบ้าง
ในตัวอย่างนี้ ก็คือการนำ Counter Component มาวางเรียงกันหลายๆอัน
(ซึ่งเวลาทำงานแล้ว แต่ละ component ก็จะ maintain state ของตัวเอง)
เริ่มด้วย Tapestry
เนื่องจากหน้าจอเราไม่ซับซ้อน ดังนั้นทางฝั่ง tapestry จึงใช้แค่ file เดียว
นั่นคือ html template file
<html>
<head>
<title>Multiple Component</title>
</head>
<body>
<span jwcid="@Counter">counter</span>
<hr/>
<span jwcid="@Counter">counter</span>
<hr/>
</body>
</html>
จะเห็นว่าเราใช้
Counter 2 อันมาวางเรียงกันลองกลับไปดูที่ฝั่ง smalltalk บ้าง
ฝั่ง smalltalk จะยุ่งยากกว่าหน่อย
ตรงที่เราต้อง maintain ว่า component MultiCounter ของเรา
มี sub component อะไรบ้าง
โดยการ maintain, seaside กำหนดให้เราต้อง
implement method
children ที่ต้อง return sub component ทั้งหมดที่อยู่ภายใต้ component เรา
WAComponent subclass: #WAMultiCounter
instanceVariableNames: 'counters'
classVariableNames: ''
poolDictionaries: ''
category: 'Seaside-Examples-Test'
initialize
super initialize.
counters _ (1 to: 2) collect: [:i | WACounter new]
children
^ counters
renderContentOn: html
counters
do: [:ea | html render: ea]
separatedBy: [html horizontalRule]
สิ่งที่แตกต่างกันมากที่สุด สำหรับ seaside กับ tapestry
ก็คือเรื่อง flow ระหว่าง page
ในฝั่ง tapestry flow ระหว่าง page
ลองดู code ฝั่ง tapestry เวลาที่เรา flow เปลี่ยน page
@InjectPage("ShowEmployee")
public abstract ShowEmployee getShowEmployee();
public IPage doSubmit() {
ShowEmployee page = getShowEmployee();
page.setEmployee(getEmployee());
return page;
}
จะเห็นว่า tapestry กำหนดไว้ว่า ถ้า method ที่ถูกเรียกใช้
return page ไหนออกมา ก็ให้ render page นั้นแทนที่ page ปัจจุบัน
ดูฝั่ง smalltalk บ้าง ลองดูตัวอย่าง การ flow ของหน้าจอขายของ
self call: (WAStoreFillCart new cart: cart)
cart := self call:
((WAStoreCartConfirmation new cart: cart)
addMessage: 'Please verify your order:')
shipping := self call:
(WAStoreAddressEditor new
validateWith: [:a | a validate];
addMessage: 'Please enter your shipping address:';
yourself)
...
WAStoreFillCart, WAStoreCartConfirmation, WAStoreAddressEditor
คือหน้าจอย่อยๆ แต่ละหน้าจอ
จะเห็นว่าเราสามารถผูกหน้าจอต่างๆเข้าเป็น flow ได้
เวลาจะกระโดดไปหน้าจอไหน ก็ใช้ method call
แถมยังรับ return ค่ากลับจากหน้าจอนั้นได้อีก
ซึ่งถือว่าเป็น feature ที่ดูเด่นกว่า tapetry อย่างเห็นได้ชัด
3 comments:
(ขออ้างก่อนว่า...ไม่สันถัดทั้ง java&smalltalk)
ดูจากที่พี่เขียน...
ผมเห็นด้วยกับความสวยงามของ smalltalk coding และคอนเซปของ smalltalk ดูเนียน..
ซึ่งน่าจะดูดีสำหรับ programmer (อย่างเราๆ)
แต่ tapestry ดูจะสะดวกในเรื่อง design มากกว่ารึป่าว?
(พูดไปพูดมาเป็นประเด็นศาสนารึป่าว? haha)
คำว่า "design" นี่หมายถึง ส่วน look & feel หรือเปล่า
ถ้าใช่ พี่ก็เห็นด้วยนะว่า
ถ้าใช้ tapestry
การทำงานระหว่าง designer กับ programmer จะทำได้ง่ายกว่า
เพราะ designer สามารถแก้ไข html, และดูผลการแก้ไข
จาก tool ของเขาได้โดยตรง (เช่น dreamweaver)
ส่วน programmer ก็ทำหน้าที่เจาะช่องร้อย component เข้าไป
ใช่ครับ design ผมหมายถึง look&feel ( ลืมไปว่า java เค้าใช้คำนี้ - -')
Post a Comment