แนวคิดของการขับเคลื่อนด้วยเหตุการณ์นั้นกว้าง อาจเป็นทางฝั่งไคลเอ็นต์หรือฝั่งเซิร์ฟเวอร์ก็ได้
ในแอปพลิเคชันเว็บ เหตุการณ์ฝั่งไคลเอ็นต์จะขึ้นอยู่กับ JS หรือปลั๊กอินหรือ JAVAAPPLET โดยพื้นฐานแล้ว หากเป็นปลั๊กอินหรือ JAVAAPPLET เหตุการณ์นั้นจะไม่ได้อยู่ในหมวดหมู่ของ HTML จริงๆ แล้ว โอกาสที่ JS ต้องเป็น ที่ใช้จริงมีไม่มากส่วนใหญ่เป็นการดำเนินการขั้นพื้นฐานเช่นการยื่นแบบฟอร์มหรือการคลิกลิงก์ดังนั้นการพูดถึงเหตุการณ์จึงไม่มีความหมาย
ความหมายที่แท้จริงของการขับเคลื่อนด้วยเหตุการณ์ไม่ได้อยู่ที่การเขียนโปรแกรมด้วยภาพ แต่อยู่ที่แนวคิด เช่นเดียวกับ OO ที่จริงแล้วการขับเคลื่อนด้วยเหตุการณ์นั้นเป็นส่วนขยายของ OO และต้นแบบดั้งเดิมของมันคือกลไกข้อความ แต่โปรแกรมควบคุมเหตุการณ์จะสรุปข้อความให้เป็นฟังก์ชันที่สามารถเรียกได้ ซึ่งคล้ายกับฟังก์ชันเรียกกลับใน API คุณสามารถกำหนดเนื้อหาการดำเนินการของฟังก์ชันเหล่านี้ได้ด้วยตัวเอง การเขียนโปรแกรมด้วยภาพจะแยกฟังก์ชันเหล่านี้ กำหนดพารามิเตอร์ (ส่วนใหญ่เป็นออบเจ็กต์สำเร็จรูป) และช่วยให้คุณสามารถเขียนโค้ดของคุณเอง และใช้พารามิเตอร์เหล่านี้ (จริงๆ แล้วคือออบเจ็กต์เหล่านี้) เพื่อทำบางสิ่งบางอย่าง
ดังนั้นจึงเป็นไปได้โดยสิ้นเชิงที่ PHP จะขับเคลื่อนด้วยเหตุการณ์ ส่วนใหญ่เนื่องมาจากการออกแบบกรอบงาน หากต้องการสร้างสิ่งที่เรียกว่าไดรเวอร์เหตุการณ์ภาพ เช่น VB คุณต้องมีสภาพแวดล้อมการพัฒนาแบบรวมที่รองรับ รวมถึงชุดของฟังก์ชันต่างๆ เช่น การออกแบบเพจ การเข้ารหัสเหตุการณ์ การคอมไพล์ และการแปลงรหัส ในความเป็นจริง สิ่งที่ขับเคลื่อนด้วยเหตุการณ์เช่น NET เพียงแค่สรุปองค์ประกอบหรือการควบคุมของเว็บที่ใช้กันทั่วไป เช่น ปุ่ม กล่องข้อความ ฯลฯ เพื่อให้คุณสามารถมีส่วนติดต่อแบบภาพในการออกแบบ หลังจากที่คอมไพล์แล้ว มันก็ยังคงเป็นข้อความเช่นนี้ เพียงแปลงโค้ดเหตุการณ์ของคุณเป็น JS หรือโค้ดฝั่งเซิร์ฟเวอร์ สำหรับ PHP สาเหตุหลักคือ IDE ไม่สมบูรณ์เพียงพอ และไม่มีกลไกการคอมไพล์ล่วงหน้า ดังนั้นโค้ดสุดท้ายที่ส่งมาจึงยังคงเป็นโค้ด PHP สุดท้าย แทนที่จะเป็นส่วนผสมของโค้ดทรัพยากร NET และโค้ดเหตุการณ์ (โดยปกติจะเป็น ASP เอกสารที่สอดคล้องกับข้อกำหนด XML มีโค้ด HTML ที่ไม่ได้มาตรฐาน) ดังนั้น PHP จึงยังไม่สามารถบรรลุสิ่งที่เรียกว่าการเขียนโปรแกรมที่ขับเคลื่อนด้วยเหตุการณ์ในความหมายที่แคบในใจของทุกคนได้ แต่ในความเป็นจริงแล้วมันไม่มีปัญหาเลย
หากคุณสนใจ คุณอาจต้องการไปที่หน้าแรกอย่างเป็นทางการ ของ www.php.net เพื่อดู PRADO ซึ่งเป็นเฟรมเวิร์ก PHP ที่ขับเคลื่อนด้วยเหตุการณ์ที่เขียนโดยเพื่อนชาวจีน (เฉียง Xue) นี่ยังคงเป็นเฟรมเวิร์กที่ดีที่สุด ได้รับการโหวตสูงและแนะนำเป็นอย่างยิ่ง โปรดดูที่ http://www.zend.com/php5/contest หลังจากอ่านซอร์สโค้ดแล้ว คุณจะเข้าใจว่าโปรแกรมควบคุมเหตุการณ์ของ PHP คืออะไร แต่ฉันคิดว่าในเรื่องนี้ เนื่องจาก PHP ไม่มีกลไกการคอมไพล์ล่วงหน้าและอาศัย OO มากเกินไป (แม้ว่าโค้ดจะเขียนด้วย PHP5) เฟรมเวิร์กนี้จึงค่อนข้างเทอะทะ ซับซ้อนในการใช้งาน และไม่สามารถปรับขนาดได้มากนัก อย่างไรก็ตาม แนวคิดนี้ดีมาก และแนวคิดบางส่วนได้แก้ไขปัญหาที่ทำให้ฉันงงใจมาหลายวันแล้ว ผมขอแนะนำกรอบการทำงานด้านล่างนี้โดยย่อ
กรอบงานเขียนด้วยภาษา ZDE และ PHP5 มีเอกสารประกอบโดยละเอียด โครงสร้างที่ชัดเจน และความคิดเห็นที่เพียงพอ โค้ดนี้อ่านง่ายมาก ซึ่งบ่งชี้ว่าระดับการเขียนโค้ดของผู้เขียนนั้นสูงมาก ผู้เขียนระบุอย่างชัดเจนว่ากรอบงานนี้อ้างอิงถึงแนวคิดของ ASP.NET และ Borland Delphi
กรอบการทำงานนี้มีความแข็งแกร่งมากในการตรวจสอบ (ไม่ใช่ว่าจะมีโมดูลใดๆ เช่น การเข้าสู่ระบบการตรวจสอบ) ที่แข็งแกร่งมากและแทบจะเป็นไปไม่ได้เลยที่จะมีช่องโหว่โดยตรงใดๆ ที่สามารถเจาะทะลุจากภายนอกได้ โดยจะแนะนำแนวคิดของข้อจำกัดของไฟล์ จะช่วยแก้ปัญหาคอขวดด้านประสิทธิภาพในการตรวจสอบขนาดใหญ่ได้อย่างมีประสิทธิภาพ ปัญหาเดียวของวิธีการตรวจสอบนี้คือการผลิตไฟล์ข้อกำหนดนั้นต้องใช้ความพยายามมากกว่า (แน่นอนว่าการใช้เครื่องมือก็เป็นอีกเรื่องหนึ่ง) ไฟล์ข้อกำหนดนั้นเอง ด้วยรูปแบบและข้อกำหนด) การตรวจสอบจะทำโดยกรอบงานโดยธรรมชาติโดยไม่จำเป็นต้องมีการเรียกจากมนุษย์ทุกครั้ง เหตุการณ์สามารถกำหนดได้ในไฟล์ข้อกำหนด (ฉันคิดว่านี่ไม่จำเป็น) ที่จริงแล้วไฟล์ข้อกำหนดค่อนข้างคล้ายกับไฟล์คำจำกัดความของ FORM ใน DELPHI หรือ VB แต่เป็นข้อความธรรมดาที่เขียนด้วย XML แทนที่จะเป็น การสร้างภาพ สำหรับการขับเคลื่อนด้วยเหตุการณ์ เฟรมเวิร์กมีชุดของโฟลว์เหตุการณ์พื้นฐานในตัวที่คล้ายกับ NET คุณสามารถปรับแต่งเหตุการณ์เหล่านี้ได้ในขั้นตอนที่แตกต่างกัน แบบฟอร์มที่กำหนด คุณยังสามารถเพิ่มเหตุการณ์ของคุณเองได้ ตัวอย่างเช่น เมื่อคุณกำหนดองค์ประกอบของคุณเอง ให้กำหนดฟังก์ชันและพารามิเตอร์ของเหตุการณ์ที่ส่วนประกอบอาจมีในไฟล์ข้อกำหนด ในอนาคต คุณสามารถกำหนดฟังก์ชันที่ได้รับอนุญาตเหล่านี้ได้โดยตรง เมื่อใช้ส่วนประกอบ - แต่ฉันคิดว่าวิธีนี้ซับซ้อนเกินไปและต้องใช้ไฟล์ XML จำนวนมากในการอ่านและวิเคราะห์ แม้ว่าจะเข้มงวดและปลอดภัยมาก แต่ก็ค่อนข้างจะมากเกินไปและไม่ได้ใช้ความยืดหยุ่นของ PHP อย่างเต็มที่ ความคิดของฉันคือการใช้สิ่งที่คล้ายกับ DELPHI โดยการกำหนดฟังก์ชั่นแฮนเดิลหรือใช้ฟีเจอร์ของฟังก์ชันโทรกลับของ C คุณสามารถกำหนดเหตุการณ์ได้ทุกที่ทุกเวลาในขณะที่เขียนโค้ดและยังสามารถระบุผู้ส่งและประเภทเหตุการณ์ได้อย่างชัดเจนและมี รับประกันความปลอดภัยที่เพียงพอโดยไม่ต้องใช้เครื่องจักร โดยบังคับให้แต่ละส่วนประกอบมีเหตุการณ์บางอย่างเท่านั้น ทำให้การแก้ไขและขยายโค้ดสะดวกมาก แน่นอนว่า เมื่อทำงานในโครงการขนาดใหญ่ จำเป็นต้องมีคำจำกัดความที่เข้มงวด แต่ถึงอย่างนั้น วิธีจัดการเหตุการณ์ของกรอบงานก็ค่อนข้างล้าสมัย
ฉันคิดว่าเทมเพลตของมันค่อนข้างคล้ายกับไฟล์ ASP ของ NET ก่อนการคอมไพล์ (ฉันไม่คุ้นเคยกับ ASP NET แต่ฉันเข้าใจหลักการบางอย่าง) แต่วิธีการทำงานคือไฟล์ FORM ที่คล้ายกับ DELPHI เป็นแนวคิดที่ดีมาก ข้อเสียเปรียบประการเดียวคือไม่สะดวกนักที่จะใช้โปรแกรมแก้ไขทั่วไปแบบ WYSIWYG เช่น DW เนื่องจากองค์ประกอบที่แยกจากกันหลายรายการสามารถรวมไว้ในเทมเพลตเดียวพร้อมกันและตัดสินใจว่าจะแสดงเฉพาะองค์ประกอบใด ระหว่างรันไทม์
เมื่อฉันดูโค้ดของเฟรมเวิร์กนี้ ฉันยังพบว่ามันมีบางรายการที่อ่อนแอมาก สิ่งที่สำคัญที่สุดคือปัญหาเส้นทาง ความสามารถในการปรับขนาดต่ำมาก ควรเหมาะสำหรับโฮสต์เฉพาะมากกว่า คุณไม่สามารถทำอะไรกับโฮสต์ที่ถูกจำกัดบางรายการได้ (ข้อจำกัดของไดเรกทอรีหรือข้อจำกัดของสิทธิ์) และไม่มีอินเทอร์เฟซที่เกี่ยวข้อง) ใช้กลไกที่ยุ่งยากที่เรียกว่า AssetService สำหรับเส้นทางของทรัพยากรหรือไฟล์บางอย่าง จุดประสงค์คือเพื่อกำหนดเส้นทางของไฟล์ ผู้เขียนเองยังกล่าวด้วยว่าหากใช้บริการนี้ ปริมาณการใช้ระบบจะเพิ่มขึ้นอย่างมาก ยืมมาจาก แนวคิดของไลบรารีสินทรัพย์ใน FLASH ช่วยให้คุณสามารถระบุเส้นทางโดยพลการ แต่จะต้องได้รับการตรวจสอบอีกครั้งทุกครั้ง ซึ่งไม่คุ้มกับผลกำไร แนวทางของฉันคือการแก้ไขเส้นทางหลักหลายๆ เส้นทาง และไดเรกทอรีย่อยของเส้นทางเหล่านั้นสามารถกำหนดเองได้ ซึ่งทำให้ความขัดแย้งระหว่างทั้งสองมีความสมดุลอย่างทั่วถึง เนื่องจากขาดการพิจารณาปัญหาเส้นทาง เฟรมเวิร์กจึงไม่มีประสิทธิภาพด้วยการตั้งค่าภาษา เทมเพลตส่วนบุคคล ฯลฯ หากคุณต้องการแปลโปรเจ็กต์ อาจเป็นไปได้ว่าขั้นตอนมีความซับซ้อน มีภาระงานมาก และง่ายต่อการ ทำผิดพลาด นี่เป็นปัญหาเดียวที่ร้ายแรงที่สุดกับกรอบงาน
โดยทั่วไปแล้ว แนวคิด การออกแบบ และโค้ดของเฟรมเวิร์กนี้ถือเป็นอันดับแรกอย่างแน่นอน แน่นอนว่ามีข้อบกพร่องอยู่เสมอ แต่สิ่งนี้ไม่ได้ขัดขวางเราจากการศึกษาและเรียนรู้มันเลย ฉันยังไม่ได้อ่านโค้ดทั้งหมด มีเพียงไม่กี่โปรแกรมหลักและคำแนะนำบางอย่างเท่านั้น แต่ฉันสามารถเห็นโครงสร้างและแนวคิดของมันได้อย่างชัดเจน ฉันชื่นชมผู้เขียนอย่างสุดซึ้ง แต่ฉันก็เสียใจอย่างสุดซึ้งต่อข้อบกพร่องเช่นกัน ไม่ว่าจะเป็นอย่างไร การเรียนรู้โค้ดที่ขับเคลื่อนด้วยเหตุการณ์ PHP ถือเป็นงานที่ดีอย่างแน่นอน ขอแนะนำอย่างยิ่ง!