หลักการของ WebDBObject (ร่าง)

ก่อนอื่นต้องขอบอกไว้ก่อนนะครับว่า โครงการนี้ไม่ได้เน้นที่จะให้เป็น Web Content Management System ขนาดใหญ่ แต่จะเน้นเพื่อใช้ส่วนตัว หรือธุรกิจขนาดเล็กเท่านั้น หรือที่เรียกว่า SOHO (Small Office Home Office) นะครับ โดยจะเน้นที่ความง่ายต่อการใช้งาน เพื่อให้ผู้ใช้ไม่ต้องมีความรู้ด้านคอมพิวเตอร์มากนัก ก็สามารถใช้งานได้ และบทความนี้ยังไม่พูดถึงการ implement ว่าจะทำอย่างไร แต่ต้องการเสนอหลักการต่างๆให้เห็นว่าผู้ใช้ จะใช้งานได้อย่างไรมากกว่า ซึ่งต้องการข้อคิดเห็นเพิ่มเติมว่าสิ่งที่ผมมองนั้นดีหรือไม่นะครับ ยังไงก็ช่วยวิจารณ์ด้วยนะครับ

ใช้งานง่าย

ต้องขอเริ่มที่ทำอย่างไรให้ใช้งานได้ง่ายนะครับ เพราะเป็นเป้าหมายหลักเลย โดยหลักการนั้น จะให้ผู้ดูแลเว็บมองเนื้อหาทั้งหมดเป็นข้อมูลล้วนๆ และจะเก็บไว้ในฐานข้อมูล แต่จะทำอย่างไรให้ผู้ดูแลไม่จำเป็นต้องเรียนรู้ เรื่องการจัดการฐานข้อมูลมากนัก ผมจึงคิดว่าถ้าให้ฐานข้อมูลแต่ละ Table ถูกมองเหมือนไฟล์ธรรมดา หรืออาจจะเปรียบได้เป็น Spreadsheet ไฟล์ คือมีข้อมูลอยู่ในนั้นเป็นคอลัมน์ๆไป น่าจะลดความซับซ้อนที่จะต้องออกแบบฐานข้อมูลไปได้ โดยจะให้ผู้ดูแลสามารถสร้างโครงสร้างของไฟล์ข้อมูลแบบของตัวเองได้ และอาจจะกำหนดให้เป็นนามสกุลแบบต่างๆ เช่น ไฟล์ที่เก็บฐานข้อมูลอีเมล์ ก็อาจจะมีนามสกุลเป็น .email เป็นต้น ในตอนที่เขาสร้างโครงสร้างนั้น จะต้องมี UI ที่ช่วยให้เขาสร้าง แบบฟอร์มสำหรับกรอกข้อมูลนั้นๆไปด้วยเลย ซึ่งจะถูกนำไปใช้ตอนที่เขาเปิดดูหรือจะป้อนข้อมูล โดยหลักการนี้จะเสมือนว่าเรามองข้อมูลเป็น Object แต่ละแบบ

อ้างถึงข้อมูลด้วย URI

เมื่อข้อมูลเสมือนเก็บอยู่ในไฟล์ การอ้างถึงข้อมูลก็น่าจะสามารถอ้างได้ด้วย URI ซึ่งจะทำให้ง่ายต่อการนำข้อมูลไปใช้งาน แต่คงจะต้องมีการกำหนดลักษณะการอ้างถึงเพิ่มเติมเพื่อให้สามารถอ้างถึงข้อมูลเป็นชุด หรือเป็นเงื่อนไขได้ ซึ่งหากใช้งานร่วมกับ WebDAV ได้ด้วยก็จะทำให้การแก้ไข/ปรับปรุงข้อมูล ก็สามารถใช้เครื่องมือง่ายๆได้ อีกทั้งยังสามารถแลกเปลี่ยนข้อมูลกันได้ง่ายขึ้นด้วย (การแลกเปลี่ยนข้อมูลจะขอพูดในตอนหลัง)

ข้อสังเกตเพิ่มเติม:(02/12/2002)

ขณะนี้ WebDAV.org ได้มีการกำหนดเพิ่มเติมเกี่ยวกับ version ของข้อมูล ซึ่งเรียกว่า DeltaV และมีโครงการสร้าง Workspace Versioning and Configuration Management API(WVCM API) ด้วยภาษาจาวา คือ JSR 147 ซึ่งมีข้อสังเกตุว่า การระบุ version นั้นจะไม่กำหนดอยู่ใน URI ซึ่งตรงนี้เขาให้เหตุผลว่า URI ที่ใช้อ้างถึง resource นั้นๆควรจะเหมือนเดิม ถ้าอ้างถึง resource อันเดิม แต่ผมก็สงสัยว่า resource คนละรุ่นกันจะถือว่าเป็น resource อันเดียวกันได้อย่างไร ในเมื่อมันไม่เหมือนกัน

การออกแบบเว็บเพจ

เมื่อต้องการแสดงผลออกมา จะกระทำผ่าน Template โดยการออกแบบ Template นั้นผมคิดว่าจะใช้ SVG เป็นพื้นฐานของทั้งหมด เพราะเป็น XML ซึ่งจะทำให้เราสามารถสร้าง XML Transformer แปลงไปเป็นการแสดงผลแบบอื่นๆได้ง่าย ไม่ว่าจะเป็น HTML หรือ PDF ฯลฯ และสามารถสร้างเป็น Template ย่อยๆ ที่จะนำไปประกอบกับ Template อื่นๆได้อีกด้วย นอกจากนี้ SVG ยังสามารถสร้างแบบที่เป็น interactive/animation ได้ด้วย ซึ่งจะทำให้ Template ที่สร้างจะเป็นได้ทั้ง Static และ Dynamic นอกจากนี้แล้ว เครื่องมือที่ใช้ออกแบบยังสามารถปรับใช้สำหรับออกแบบ Web Programming ได้อีกด้วย

ข้อสังเกตเพิ่มเติม: (09/12/2002)

โครงการ Mozilla ได้สร้างเครื่องมือ XPTool และภาษาสำหรับใช้เป็น UI คือ XUL (XML-based User Interface Language) ซึ่งค่อนข้างน่าสนใจ เพราะคงจะเป็นส่วนหนึ่งของ Netscape browser ด้วย แต่เท่าที่อ่านดูโครงสร้างของ XUL นั้นพบว่าเหมาะกับการสร้างในแบบ Text based มากกว่า และค่อนข้างตายตัวไปเลย เช่น มี window, menu, button ฯลฯ แต่สำหรับ SVG นั้นเป็น Vector graphic อย่างแท้จริง ซึ่งมีความอ่อนตัวกว่า XUL คือเราอยากวาดอะไรก็วาดได้ตามต้องการ สรุปว่า XUL จะสำเร็จรูปมากกว่า ซึ่งจะทำให้สร้างได้เร็วและง่าย แต่ตายตัว กว่า SVG

ข้อสังเกตเพิ่มเติม: (08/01/2003)

มีบทความเกี่ยวกับการใช้ SVG กับ Web Application ที่น่าสนใจ ซึ่งตอกย้ำแนวคิดของผมที่จะใช้ SVG ได้เป็นอย่างดี

บทความเรื่อง Bringing SVG Power to JavaTM Applications
By Christophe Jolif, January 2003
URL: http://developer.java.sun.com/developer/technicalArticles/GUI/svg/

เพิ่มบริการ

บริการต่างๆนั้น ควรจะทำให้สามารถเพิ่มเติมได้ง่ายๆ เหมือนการติดตั้งโปรแกรม คือมีการถามข้อมูลตอนติดตั้งเท่านั้น เสร็จแล้ว ถ้าต้องการปรับเปลี่ยน ควรจะติดต่อกับผู้ใช้เหมือนการใช้ Control Panel ของ Windows โดยบริการนี้จะเป็น module ที่อาจจะประกอบด้วย Object Type, Template, Viewer/Editor, ฯลฯ เพื่อช่วยให้ผู้ใช้นำไปประกอบเป็นหน้าบริการตามที่เขาต้องการ

Generate

จากที่ข้อมูลทั้งหมดถูกเก็บไว้ในฐานข้อมูล ถ้าการเปิดแต่ละหน้า แต่ละครั้งต้องเรียกผ่านฐานข้อมูลตลอด อาจจะทำให้ไม่มีประสิทธิภาพพอ ซึ่งถ้าข้อมูลบางอย่างที่อยู่ในฐานข้อมูลนั้นไม่ได้เปลี่ยนแปลงโดยผู้เข้าชมแล้ว เว็บเพจหน้าต่างๆที่ใช้ข้อมูลนี้จะไม่เปลี่ยนแปลง ทำให้สามารถสร้างเป็น static page ได้ โดยกลไกภายในจะสามารถตรวจสอบตรงนี้ได้ด้วยการตรวจสอบความสัมพันธ์ของ Template กับข้อมูล

การแลกเปลี่ยนข้อมูล (Transfer)

โดยปกติแล้ว ผู้ดูแลจะมีข้อมูลทั้งหมดเก็บไว้ที่เครื่องของตัวเอง และเมื่อออกแบบเสร็จแล้วก็จะส่งไปไว้ที่ server อีกตัวหนึ่ง ซึ่งโปรแกรมทั้งสองฝั่งควรจะติดต่อสื่อสารกันได้เป็นอย่างดี (ปกติจะใช้ FTP, DAV ฯลฯ) โดยจะทำให้การส่งข้อมูลไปทำได้สะดวกขึ้น และถ้าสามารถสื่อสารกันได้ว่า มีข้อมูลใดบ้างที่เปลี่ยนแปลง แล้วส่งเฉพาะข้อมูลที่เปลี่ยนแปลงนั้นไปให้ จะทำให้การส่งข้อมูลรวดเร็วและมั่นใจได้ว่าไม่ผิดพลาด การสื่อสารกันแบบนี้ถ้ามองอีกมุมหนึ่ง จะเป็นการสื่อสารระหว่า server กับ server ครับ เพราะว่าที่เครื่องของผู้ออกแบบ น่าจะมี server ไว้สำหรับ preview อยู่ด้วย หากเรามองแบบนี้ และวางมาตรฐานการสื่อสารระหว่าง WebDBObject server ให้ดีแล้ว จะสามารถนำกลไกนี้ไปใช้ด้านอื่นๆได้อีกด้วย เช่น การแลก banner กันระหว่าง server, การแลกข่าวสารหรือทรัพยากรกัน, การปรับเปลี่ยนลิ้งค์ที่มีการอ้างไปยัง/จากเว็บอื่นได้อย่างอัตโนมัติทั้งเครือข่าย หรือแม้แต่การจะทำ distributed processing กันก็อาจจะเป็นไปได้

การติดต่อกับผู้ใช้(ผู้ดูแล/ออกแบบเว็บ)

จากที่กล่าวมาทั้งหมดนั้น จะเห็นได้ว่า ผู้ดูแลหรือผู้ออกแบบเว็บเพจนั้น ต้องการความสามารถของ UI สูง ดังนั้น การติดต่อจะไม่ทำผ่าน browser เหมือนอย่างโปรแกรมอื่นๆ แต่จะติดต่อด้วย Client Application ที่ออกแบบมาเฉพาะเลย โดย Application อันนี้จะติดต่อกับ server (local หรือ remote ก็ได้) ผ่านมาตรฐานการสื่อสารดังที่กล่าวไปแล้ว

ตัวแปลง (Converter ไว้ทีหลัง)

แน่นอนครับว่า เครื่องมือต่างๆที่สร้างขึ้นคงไม่สามารถทำให้ถูกใจทุกๆคนได้ จึงควรจะมีตัวแปลงที่ฉลาด สามารถแปลง HTML หรือไฟล์อื่นๆที่ออกแบบด้วยเครื่องมืออื่นเข้ามาสู่ฐานข้อมูลและ Template ของเราได้

แหล่งข้อมูลเพิ่มเติม

1. Tomcat (http://jakarta.apache.org/tomcat/index.html)
2. Slide (http://jakarta.apache.org/slide/index.html)
3. Avalon (http://jakarta.apache.org/avalon/)
4. Cocoon (http://xml.apache.org/cocoon/index.html)
5. cmsInfo.org (http://www.cmsinfo.org)
6. MMBase (http://www.mmbase.org)
7. OpenCms (http://www.opencms.org)
8. Zope (http://www.zope.org) - Python
9. SVGOpen.org (http://www.svgopen.org)
10. WebDAV.org(http://www.webdav.org)
11. JSR 170: Content Repository for JavaTM technology API