Sunday, October 02, 2005

เริ่มทดลอง Tapestry 4

ช่วงนี้ Tapestry ออก version beta-8 แล้ว
ปลายปีนี้คงได้ฤกษ์ release แล้ว
ก็เลยได้ฤกษ์ load มาทดลองเหมือนกัน

เล่าย้อนหลังสำหรับคนที่ไม่รู้จัก Tapestry หน่อยหนึ่ง
ตัว Tapestry เป็น Framework ที่ใช้พัฒนา Web Application
มี model แบบ Component model
ทำให้ reuse component ได้ดี

ต้นเหตุที่ผมเปลี่ยนมาใช้เจ้า Tapestry ก็คือ
เจ้า struts มันไม่ค่อย productive ในด้าน ui เท่าไร
การ reuse source code ทำได้ยาก
จริงๆแล้วสามารถ reuse ในลักษณะ taglib ก็ได้แหล่ะ
แต่ปัญหาคือ มันมองไม่เห็นว่าหน้าตาเป็นอย่างไร
จนกว่าจะ run จริง
ส่วน tapestry ออกแบบมาให้เรา map component
เข้ากับ html page
ดังนั้นเราสามารถออกแบบ html page โดยใช้ wyswyg tool ได้
จากนั้นก็ค่อยๆ map component เข้ากับ html element ต่างๆ

ปัญหาของ tapestry อยู่ตรง
learning curve ค่อนข้างสูง
ตัว document ค่อนข้างน้อย
ปัจจุบันมีหนังสือแค่ 2 เล่มเองที่อธิบาย tapestry
(จริงๆมี 3 เล่ม แต่เล่มที่ 3 เป็นภาษาเยอรมัน ก็เลยไม่นับ)
แต่ถ้าผ่าน learning curve มาได้เมื่อไร
ก็เหมือนได้ติดปีกแล้ว, productivity ที่ได้ดีมาก

ปัจจุบัน ผมมีเกณฑ์ในการ implement project ดังนี้
กรณีที่เป็น Application ใหญ่ๆ ใช้ Tapestry + Spring + Hibernate
ถ้า App มีลักษณะที่ต้อง integrate legacy หรือระบบที่คนอื่นทำไว้ด้วย
จะเพิ่ม ServiceMix เข้าไปด้วย
แต่ถ้าเป็น App เล็กๆ ก็จะเปลี่ยนไปใช้ RubyOnRails แทน
นอกจากนี้ยังมอง solution แบบลูกผสมไว้ด้วย
นั่นคือ ในกรณีที่เป็น CRUD ธรรมดา
(พวก maintain base table)
ก็จะใช้ RubyOnRails เข้ามา
ส่วนที่ complex ค่อยใช้ Tapestry เข้ามาจัดการ
(ใช้ CAS เป็น single sign-on ระหว่าง tapestry กับ Rails)

กลับมาเข้าเรื่อง Tapestry ต่อ
ใครที่ยังไม่เคยใช้เลย ขอแนะนำว่าควรเริ่มต้นที่ version 3 ก่อน
เพราะ stable แล้ว
ส่วน version4 บอกได้คำเดียวว่า แค่ install ก็ยุ่งแล้ว

Tapestry version 4 มีการ restructure
โครงสร้างภายใน โดยเปลี่ยนไปใช้ hivemind เป็นแกน
ทำให้เราสามารถ ถอดเปลี่ยน module ภายในของ tapestry ได้ง่าย
(ในอีกทาง การเพิ่ม hivemind ก็ทำให้
ต้องเพิ่ม learning curve ที่ต้องรู้จัก hivemind เพิ่มอีกตัว)
Feature ที่สำคัญตัวหนึ่งของ hivemind
ก็คือ Configuration Points
ถ้าใครเคย implement Plugin บน Eclipse Platform
พอเห็น Concept Configuration Points
ก็คงจะได้กลิ่น Concept Extension point ของ Eclipse ขึ้นมาตะหงิดๆ

Related link from Roti

2 comments:

Anonymous said...

-QUOTE-
กรณีที่เป็น Application ใหญ่ๆ ใช้ Tapestry + Spring + Hibernate
ถ้า App มีลักษณะที่ต้อง integrate legacy หรือระบบที่คนอื่นทำไว้ด้วย
จะเพิ่ม ServiceMix เข้าไปด้วย
แต่ถ้าเป็น App เล็กๆ ก็จะเปลี่ยนไปใช้ RubyOnRails แทน
นอกจากนี้ยังมอง solution แบบลูกผสมไว้ด้วย
นั่นคือ ในกรณีที่เป็น CRUD ธรรมดา
(พวก maintain base table)
ก็จะใช้ RubyOnRails เข้ามา
-QUOTE-

ผมเพิ่งเริ่มศึกษา ROR แต่เท่าที่ดู architecture ก็ไม่เห็นว่าจะไม่เหมาะกับการพัฒนา application ขนาดใหญ่ตรงไหนนี่ครับ ตัวอย่าง

http://weblog.rubyonrails.org/archives/2005/10/11/major-healthcare-application-switches-from-j2ee-to-rails

หรือมีปัจจัยอย่างอื่นนอกจาก feature หรือ architecture ในการเลือกใช้ technology ด้วยครับ

PPhetra said...

กรณีของผม
ผมมองปัจจัยเรื่องผู้ร่วมพัฒนาด้วยครับ
กรณี app ใหญ่ที่ต้องทำกันหลายคน
จะมีประเด็นเรื่อง skill ที่ไม่เท่ากัน
ความรอบคอบ ก็ไม่เท่ากัน
ซึ่งการใช้ Ruby มันอิสระกว่า java เยอะ
กลัวเป็นดาบ 2 คมครับ
(สรุปว่า ใจยังไม่ถึงครับ
ไว้ถ้ามีประสบการณ์พัฒนา ด้วย RoR
ในลักษณะเป็น team เมื่อไร
อาจจะเปลี่ยนใจก็ได้)