ด้วยสถานะ D8 ปัจจุบันโครงสร้างการตัดสินใจสำหรับการสร้างเอนทิตีเนื้อหาแบบใหม่กับการสร้างประเภทเนื้อหาสำหรับเอนทิตีเนื้อหา“ โหนด” คืออะไร

เราได้เห็นสี่ปีและรุ่นแรกของ Drupal 8 ตั้งแต่คำตอบที่ยอมรับได้ถูกเขียนขึ้นสำหรับคำถามที่ว่า " เมื่อใดจึงเหมาะสมที่จะสร้างเอนทิตีแทนที่จะเพิ่งเพิ่มประเภทเนื้อหาใหม่ " และเอนทิตีนั้นสำคัญยิ่งกว่า Drupal 8 มากกว่าใน Drupal 7 ( RefB , RefC , RefD )

ในโลกใหม่ของ Drupal 8 โครงสร้างการตัดสินใจสำหรับการสร้างเอนทิตีเนื้อหาใหม่เมื่อเทียบกับประเภทเนื้อหาใหม่สำหรับเอนทิตีเนื้อหาประเภท "โหนด" คืออะไร

เมื่อคุณพิจารณาคำตอบโปรดพิจารณาสิ่งต่อไปนี้:

• ประเภทเนื้อหาใหม่สำหรับประเภทเอนทิตีเนื้อหาของ "โหนด" ยังคงเหมาะสมในสถานการณ์ 99% เมื่อเทียบกับประเภทเอนทิตีเนื้อหาใหม่หรือไม่
• โครงสร้างการตัดสินใจในขณะนี้มีเหตุผลที่ดีกว่าดีกว่าหรือชัดเจนกว่าในการหลีกเลี่ยงการใช้ชนิดเอนทิตีเนื้อหา "โหนด" และสร้างประเภทเอนทิตีเนื้อหาใหม่แทนหรือไม่ และถ้าใช่พวกเขาคืออะไร พวกเขารวมถึง:
  • ประสิทธิภาพ?
  • การรักษาความปลอดภัย / สิทธิ์?
  • จำนวนโมดูลที่ทำงานกับ Node-entity-type Content-Types และไม่ทำงานกับเอนทิตีเนื้อหาอื่น ๆ ?
• บางที - จากคำตอบที่ยอมรับก่อนหน้านี้ที่อ้างถึงข้างต้น - เหตุผลทั่วไปเพียงอย่างเดียวในการทำประเภทเนื้อหาที่กำหนดเองคือถ้าคุณต้องการจัดกลุ่มข้อมูลโหนดเช่นด้วยเงื่อนไขอนุกรมวิธานหรือหมายเหตุประกอบโหนดอื่นเช่นแสดงความคิดเห็น?

ความเข้ากันได้ของโมดูลดูเหมือนจะเป็นการพิจารณาที่น่าสนใจเป็นพิเศษสำหรับโครงสร้างการตัดสินใจ ในปัจจุบันมีโมดูลที่ติดตั้งส่วนใหญ่จำนวนไม่น้อยที่มีการเปิดตัวสำหรับ 8.x ซึ่งไม่เพียง แต่เป็นอัลฟ่าเบต้าหรือ rc (ตัวเลือกการเปิดตัว) และดูเหมือนยากที่จะระบุจำนวนของพวกเขาที่จะทำงานนอกกรอบด้วยประเภทเอนทิตีที่กำหนดเองใหม่เมื่อเทียบกับประเภทเนื้อหาโหนดเอนทิตีใหม่ ไม่ปรากฏว่ามีแอตทริบิวต์โครงการเพื่อแยกความแตกต่างระหว่าง "การเขียนสำหรับเอนทิตี" และ "เขียนสำหรับชนิดเนื้อหาเอนทิตีโหนด"

ลองดูที่ pathauto ซึ่งปัจจุบันเป็นโมดูลที่ติดตั้งมากที่สุดเป็นอันดับที่สี่ของโมดูลที่มีรุ่น 8.x Folks กำลังทำงานอย่างหนักกับเวอร์ชัน 8.x ที่รองรับเอนทิตีและไม่ใช่แค่ประเภทเนื้อหาของโหนด - เอนทิตี แต่โมดูลอื่น ๆ ทั้งหมดล่ะ? และโมดูลที่สนับสนุนเอนทิตีจะต้องมีประเภทเอนทิตีเนื้อหาที่กำหนดเองเพื่อให้มี "hooks" เฉพาะโมดูลก่อนที่โมดูลจะทำงานกับพวกเขาหรือไม่ (เมื่อเทียบกับวิธีการที่โมดูลอาจทำงานได้ทันทีด้วยประเภทเนื้อหาใหม่?) ที่ดูเหมือนจะเป็นชนิดของความท้าทายที่ทีมงาน pathauto ทำงานด้วยและบางทีมันเป็นเหตุผลที่จะแยกแยะประเภทเนื้อหาที่กำหนดเอง?

อาจกล่าวได้ว่า Drupal 8 core มี UI สำหรับการสร้างประเภทเนื้อหาใหม่สำหรับเอนทิตีเนื้อหาของประเภท "โหนด" แต่ปัจจุบันยังไม่มี UI สำหรับการสร้างประเภทเอนทิตีเนื้อหาใหม่ ( RefX , RefY , RefZ )

แผนผังการตัดสินใจสำหรับการเลือกระหว่างการสร้าง Node-entity-type ชนิดเนื้อหาใหม่กับเอนทิตีเนื้อหาใหม่:

1. คุณเป็นโปรแกรมเมอร์หรือคุณมีความสะดวกในการเข้าถึงโปรแกรมเมอร์หรือไม่?
   • หากไม่แสดงว่าคุณมีข้อ จำกัด ในการสร้างประเภทเนื้อหา Node-entity ใหม่ (ไม่มี UI ในแกนหลักสำหรับการสร้างประเภทเอนทิตีเนื้อหาใหม่และโมดูลการควบคุมEntity Construction Kit (ECK)ปัจจุบันมีเฉพาะรุ่นอัลฟาเท่านั้น)
   • ถ้าใช่ให้ทำต่อ ...
2. คุณรู้หรือไม่ว่าโมดูล contribใดที่คุณต้องการใช้ประโยชน์จากข้อมูลของคุณ?
   • ถ้าไม่แสดงว่าการเดิมพันอย่างปลอดภัยนั้นอาจสร้างเพียงประเภทเนื้อหาของโหนด
   • ถ้าใช่โมดูลเหล่านั้นสนับสนุนประเภทเอนทิตีที่กำหนดเองที่คุณกำลังพิจารณาอยู่หรือไม่หรือคุณยินดีที่จะช่วยปรับปรุงโมดูลเหล่านั้นเพื่อพวกเขาจะหรือสร้างฟังก์ชันการทำงานที่ต้องการในโมดูลของคุณอีกครั้ง
     • ถ้าไม่ใช่แค่สร้าง Node-entity-type Content Type อาจจะดีที่สุดสำหรับคุณ
     • ถ้าใช่ให้ทำต่อ ...
3. ข้อมูลเนื้อหาจริงที่โมดูลของคุณเปิดใช้จะช่วยให้กลุ่มหรือใส่คำอธิบายประกอบข้อมูลเนื้อหาอื่น ๆ ได้หรือไม่ (เพื่อที่จะไม่ค่อยได้รับชมด้วยตัวเอง)
   • ถ้าใช่ให้พิจารณาว่าโมดูลของคุณเป็นประเภทนิติบุคคลที่มีอยู่สำหรับข้อกำหนดและความคิดเห็นทางภาษี ถ้าเป็นเช่นนั้นประเภทนิติบุคคลใหม่อาจเป็นทางออกที่ปลอดภัย
   • ถ้าไม่ก็ทำต่อ ...
4. คุณสามารถอธิบายได้อย่างชัดเจนหรือไม่ว่าทำไม Node-entity-type Content Type ใหม่ถึงใช้งานไม่ได้สำหรับคุณ?
   • ถ้าไม่แสดงว่าการเดิมพันที่ปลอดภัยของคุณคือการสร้างประเภทเนื้อหา Node-entity-type ใหม่
   • ถ้าใช่ให้ทำต่อ ...
5. สุดท้ายคุณแน่ใจหรือไม่ว่าคุณไม่สามารถขยาย Node-entity-type และคุณต้องการสร้างฟังก์ชันการทำงานที่มีประโยชน์ทั้งหมดเช่นการดำเนินการ CRUD อีกครั้ง
   • ถ้าใช่ให้ดำเนินการต่อและสร้างประเภทเอนทิตีที่กำหนดเองใหม่
   • ถ้าไม่หรือถ้าคุณไม่แน่ใจคุณอาจต้องการว่าจ้างผู้เชี่ยวชาญเพื่อช่วยในการตัดสินใจ

หมายเหตุ:

1. แผนผังการตัดสินใจนี้ไม่พิจารณาประสิทธิภาพหรือความปลอดภัย ฉันไม่แน่ใจว่าหรือเมื่อประเภทเอนทิตีเนื้อหาที่กำหนดเองใหม่จะทำงานได้ดีขึ้นและมีความปลอดภัยมากกว่าหรือน้อยกว่า Node-entity-type
2. แม้ว่าทรีนี้จะเป็นคำตอบที่ดี แต่ก็อาจจะไม่เหลืออยู่ตลอดเวลาเนื่องจากการอัพเดทใน Drupal core และ contrib module release StackExchange ดูเหมือนจะไม่รองรับว่าคำตอบที่ "ดีที่สุด" ในวันนี้อาจไม่ใช่คำตอบที่ดีที่สุดในวันพรุ่งนี้)

วิธีการง่าย ๆเกี่ยวกับปัญหานั้นคือการพิจารณาวัตถุประสงค์ของโครงการขนาดและความต้องการทางธุรกิจ

1. วิธีที่ประเภทเนื้อหาของโหนดเอนทิตีเริ่มต้นส่งผลกระทบต่อการสร้างโครงการในวิธีที่ง่ายและเรียบร้อยใกล้กับสถาปัตยกรรมและการไหลของข้อมูลที่เกิดจากการคิดวิเคราะห์ของเอกสารโครงการ

การแจ้งเตือนสำคัญที่นี่การตัดสินใจสร้างเอนทิตีแบบใหม่มักจะใช้เวลาโดยนักพัฒนาหรือผู้นำด้านเทคนิคไม่ใช่ผู้สร้างไซต์หรือเจ้าของโครงการที่จัดการแอปพลิเคชันและมุ่งเน้นเฉพาะธุรกิจ

2. Drupal 8ขึ้นอยู่กับแพคเกจ symfony2 บางอย่างและใกล้เคียงกับเฟรมเวิร์กมากขึ้นการพัฒนาที่ cms แบบดั้งเดิมพูดถึง Drupal ด้วยการเปลี่ยนแปลงทางสถาปัตยกรรมครั้งใหญ่ฉันจินตนาการว่าการสร้างเอนทิตีใหม่นั้นดีกว่าการปรับแต่งเอง เพื่อยกระดับ Drupal ท่ามกลางกรอบงานอื่น ๆ เนื่องจากหลาย ๆ คนไม่ชอบวิธีการตั้งค่าและการตั้งค่าแบบกระจายของ Drupal คุณอาจพบว่าบางคนมาจาก WordPress และใช้ตั้งค่าทุกอย่างจากรูปแบบเดียวซึ่งทำให้พวกเขารำคาญเมื่อต้องจัดการกับแดชบอร์ด

3. Drupal 9วางแผนที่จะลบระบบ hook ทั้งหมดและแทนที่ด้วยตัวเลือกเหตุการณ์ที่นำไปสู่ความต้องการขนาดใหญ่สำหรับอินเทอร์เฟซผู้ดูแลระบบเพื่อสร้างเอนทิตีใหม่เนื่องจากการปรับเปลี่ยนการทำงานที่มีอยู่จากรหัสจะยากกว่ามากสำหรับคนที่ไม่ใช่นักพัฒนา เพิ่มคุณสมบัตินั้น

ในตอนท้ายฉันเห็นเอนทิตีใหม่ที่ปรับให้เหมาะกับความต้องการของโครงการให้ประสิทธิภาพสูงกว่าเนื้อหาที่ซับซ้อนที่มีฟิลด์จำนวนมากเนื่องจากเราตอนนี้แต่ละฟิลด์เพิ่ม 2 ตารางลงในฐานข้อมูลและจำเป็นต้องโหลดการกำหนดค่าตามคำขอแต่ละรายการ ต้องใช้ตรรกะทางธุรกิจอย่างหนัก

ธรรมดาและเรียบง่าย: มันไม่ใช่เนื้อหาทั้งหมด รายการเนื้อหาอาจใช้เวลานานและทำให้เกิดความสับสนหากคุณเพียงแค่ใช้ประเภทเนื้อหา ( ContentEntityBaseยังสามารถนำมาใช้โดยองค์กรที่กำหนดเอง)

หากคุณมีผู้เขียนและเผยแพร่สถานะคุณควรไปสำหรับประเภทเนื้อหา

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

ในมุมมองของฉันนี้เป็นเพียงสถาปัตยกรรมที่ชัดเจนและสั่งหาง (และยังมีประสิทธิภาพมากขึ้น)

ความคิดของสามารถนำมาใช้ในหลายโครงการพยายามที่จะทำให้หน่วยงานที่กำหนดเองระเบิดออก .. นอกจากนี้ยังมีผู้ช่วยเหลือที่ดีเช่นDrupal รหัสกำเนิด เพื่อให้การเข้ารหัสที่กำหนดเอง (หรือความซับซ้อน) อยู่ในระดับต่ำคุณควรพิจารณาใช้ประเภทเนื้อหาหากคุณต้องการ:

• ในการแปล 'เอนทิตี' (อย่างน้อยใน D7) ก็จะมีส่วนต่อประสานด้วย
• (เปิดสำหรับคำแนะนำ) ..

มันเป็นคำถามที่ยากมากที่ฉันคิดว่าเข้าใจโดยสุจริตเมื่อคุณนำไปใช้งานมาก่อน แต่เป็น metioned Remy, ทุกอย่างไม่ได้เป็นวัตถุดิบเนื้อหาที่ผู้ใช้หันหน้าไปทาง

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

ใน Drupal 8 ความคิดนั้นได้รับการยอมรับมากขึ้นและเป็นเรื่องง่ายขึ้นที่จะเริ่มต้นใช้งานเอนทิตีแบบกำหนดเอง โหนดเองมีพื้นฐานจาก ContentEntityBase เช่นเดียวกับบล็อกผู้ใช้ไฟล์และ Taxonomy

โหนดมีไว้สำหรับข้อมูลเนื้อหาที่ตีพิมพ์เผยแพร่ (หรือได้รับอนุญาต) ซึ่งโดยทั่วไปจะทำหน้าที่เป็นเนื้อหา (นั่นคือในเมนูหรือในแผนผังไซต์หรือ xml แผนผังไซต์หรือฟีด RSS ฯลฯ ) Drupal ได้รับการออกแบบในลักษณะที่คุณสามารถเชื่อมต่อไปยังขั้นตอนของกระบวนการของการดำเนินการของโหนดและแก้ไขซึ่งอาจมีผลที่ไม่ตั้งใจถ้าคุณมีการผสมผสานที่ผิดพลาดของโมดูลที่สนับสนุน นี่อาจเป็นความเห็นแย้ง แต่ช่วยหย่าร้างตัวเองจากแนวคิดของ "ทุกอย่างเป็นโหนด" เพื่อโอบกอดแนวคิดของเอนทิตี้มากขึ้น

เนื้อหาในอุดมคติที่สร้างเนื้อหาที่ยอดเยี่ยม:

• บทความ
• หน้า
• การโพสต์งาน
• เหตุการณ์
• หน้า Landing
• โฮมเพจ

เธรดทั่วไปสำหรับพวกเขาคือพวกเขาแบ่งปันแนวคิดของประเภทเนื้อหา โดยปกติจะอยู่ในสถานะเวิร์กโฟลว์ใด ๆ (เผยแพร่เลื่อนขั้นเหนียวเก็บถาวรแนะนำ ฯลฯ - หากคุณใช้ตัวเลือกการเผยแพร่แบบกำหนดเอง) และโมดูลที่สนับสนุนจำนวนมากโต้ตอบกับมันโดยตรงเช่น Pathauto

แต่ให้สมมติว่าคุณต้องการเก็บข้อมูลใน Drupal ที่เป็นข้อมูลภายในส่วนตัวขับข้อมูลอื่นหรือข้อมูลที่ไม่ควรอนุญาตการรวมนอกขอบเขตยกเว้นว่าคุณอนุญาต นี่เป็นข้อมูลประเภทใด นี่คือบางประเภทที่เป็นไปได้:

• ผลิตภัณฑ์ (Drupal Commerce)
• รายการโฆษณา (Drupal Commerce)
• ค้นหาเซิร์ฟเวอร์ (ApacheSolr / SearchAPI)
• ติดต่อ (เช่นลูกค้าเป้าหมาย CRM)
• ตั๋ว (เช่นตั๋วสนับสนุน)

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

จากที่นี่ส่วนใหญ่จะถูกแยกออกจากส่วนอัตโนมัติเพิ่มเติมของระบบ Drupal / Node และคุณสามารถปรับแต่งการกระทำและประสบการณ์ คุณกำหนดเส้นทางการเข้าถึงและเวิร์กโฟลว์ CRUD

ในความคิดนั้นมันทำให้ง่ายต่อการดูว่าทำไมวิธีการที่จะทำเช่นนั้น ใช้ตัวอย่างตั๋วการสนับสนุน - เป็นคำขอที่เข้ามา แต่ไม่มีการเผยแพร่ข้อมูลและน่าจะมีเวิร์กโฟลว์เฉพาะที่ง่ายต่อการติดตั้งในแบบของคุณมากกว่าที่จะหย่าจากส่วนของระบบโหนดที่คุณไม่ต้องการให้เป็นไปตาม ไปยัง

อีกตัวอย่างหนึ่งคือข้อมูลภายนอกที่นำเข้า ในกรณีส่วนใหญ่ข้อมูลนี้มักไม่ได้รับการเสริมด้วยข้อมูล Drupal ในพื้นที่ (แม้ว่าคุณจะยังสามารถทำสิ่งนี้ได้ในฐานะนิติบุคคล) มันอาจเป็นอะไรก็ได้ บางทีมันอาจจะเป็นใบแจ้งหนี้บางทีพวกเขาอาจจะเป็นหนังสือบางทีอาจเป็นเพราะการดึงแบรนด์เบียร์

ข้อมูลเช่นนี้มักจะเฉพาะเจาะจงและต้องการการควบคุมที่เกินความหมายของโหนด ไม่ได้หมายความว่าคุณไม่สามารถเพิ่มได้โดยใช้เขตข้อมูลอ้างอิงบนโหนดเพื่อชี้ไปยังเอนทิตีที่กำหนดเองของคุณ (นี่คือวิธีที่ Drupal Commerce ทำงานในระดับหนึ่ง) เพื่อเพิ่มประสิทธิภาพให้กับข้อมูล ในเวลาเดียวกันคุณกำลังแยกและสร้างความมั่นใจในการควบคุมข้อมูลและ UI ของคุณจากรหัส contrib ที่ผิดพลาดเกินกว่าที่จะออกแบบและรบกวนโมเดลของคุณ นี่น่าจะเป็นปัญหาใน D8 น้อยกว่าใน D7 แม้ว่าจะมีตะขอบางตัวอยู่

สถาปัตยกรรมที่เหมาะสมในขณะนี้มีอยู่เพื่อส่งเสริมการแยก ไม่ใช่ทุกอย่างที่เป็นโหนด