เมื่อใดจึงจะเหมาะสมในการสร้างเอนทิตีกับเพิ่งเพิ่มประเภทเนื้อหาใหม่

ประโยชน์ที่จะได้รับจากการสร้างประเภทเอนทิตีใหม่คือเพียงแค่สร้างประเภทเนื้อหาใหม่

ดูเหมือนว่าจะใช้เวลามากเกินไปในการทำรหัสที่กำหนดเองทั้งหมดซึ่งจำเป็นในการสร้างเอนทิตีใหม่เมื่อคุณมีฟังก์ชัน CRUD และมุมมองทั้งหมดที่มีอยู่แล้วในประเภทเนื้อหา

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

ฉันคิดเสมอว่าtaxonomy_termประเภทเอนทิตีเป็นตัวอย่างที่ดีว่าทำไมทุกอย่างไม่ควรเป็นประเภทโหนด / เนื้อหา:

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

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

ฉันคิดว่าคำตอบง่ายๆคือเมื่อโหนด / ประเภทเนื้อหาไม่ได้ทำสิ่งที่คุณต้องการหรือเป็นจำนวนมากเกินไป / ค่าโสหุ้ยเพื่อประโยชน์น้อยมากคุณควรเลือกเขียนเอนทิตีที่กำหนดเอง

นี่ขึ้นอยู่กับประสบการณ์ส่วนตัวของฉันเท่านั้น ฉันสนใจที่จะฟังสิ่งที่คนที่เกี่ยวข้องโดยตรงกับการพัฒนาหลักของ Drupal ต้องพูดถึงเรื่องนี้

กฎง่ายๆที่ฉันใช้คือเนื้อหาของคุณต้องแสดงต่อสาธารณะด้วยตัวเองหรือไม่ ถ้าเป็นเช่นนั้นไปหาโหนดถ้าไม่เลือกเอนทิตี ตอนนี้เอนทิตีฟอร์มช่วยให้คุณสามารถสร้างอินเทอร์เฟซเพื่อกรอกเอนทิตีของคุณ

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

กิจการหมายถึงเฉพาะกรณีการใช้งาน

ฉันเชื่อว่าเครดิตสำหรับคำจำกัดความง่ายๆนี้ไปที่Fagoแต่ฉันขี้เกียจที่จะหาข้อมูลอ้างอิง

เราสามารถใช้Content(aka Nodes) สำหรับทุกกรณีการใช้งานหากเราต้องการ แต่บ่อยครั้งที่มันไม่สมเหตุสมผล

Content มีผู้แต่งและการตั้งค่าสำหรับความคิดเห็นและตำแหน่งเมนู

Usersเป็นตัวแทนของกรณีการใช้งานที่แตกต่างจากคนทั่วไปContentเพราะในกรณีใดกรณีหนึ่งuserข้างต้นไม่มีเหตุผลใด ๆ ในขณะที่ในทางกลับกันuserต้องมีอีเมลและรหัสผ่าน

Taxonomy terms โดดเด่นเพราะมีฟังก์ชั่นในตัวที่จะจัดเรียงในลำดับชั้นแม้แต่แบบวงกลม

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

นอกจากนี้ยังมี An Introduction to Entitiesแต่น่าเสียดายที่มันไม่ได้ตอบคำถามของคุณ

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

• ฟอรั่ม
• โครงการ (ในแง่ของการจัดการโครงการ)
• ฟอร์ม
• ตั๋วสนับสนุน
• กลุ่ม

ในขณะที่คุณสามารถใช้โหนดสำหรับบางอย่างเช่นตั๋วการสนับสนุนอาจไม่ใช่เทมเพลตและค่าเริ่มต้นที่ดีที่สุด ... หวังว่าจะช่วยได้

สามารถสร้างเอนทิตีได้โดยมีค่าใช้จ่ายน้อยกว่าโหนดเนื่องจากไม่จำเป็นต้องมีฟังก์ชั่นหนักทั้งหมดที่เอนทิตีมี

นอกจากนี้ยังหมายถึงพื้นที่เก็บข้อมูลสามารถทำได้ง่ายขึ้น - คุณสามารถสร้างพื้นที่เก็บข้อมูลเพื่อค้นหาข้อมูลง่ายๆโดยไม่ต้องเข้าร่วมหากคุณต้องการ เขตข้อมูลทั้งหมดอยู่ในตารางที่เป็นระเบียบเรียบร้อยเพียงตารางเดียว

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

ประเภทเนื้อหาได้รับการออกแบบให้เป็นเนื้อหาของไซต์ กล่าวคือเนื้อหาแต่ละประเภทได้รับการออกแบบให้เผยแพร่และปรากฏบนเว็บไซต์ ตัวอย่างเช่นบทความ (นอกกรอบ) ได้รับการออกแบบให้ปรากฏในหน้าแรก

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

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

จากนั้นคุณจะเข้าสู่ Drupal Commerce ซึ่งเป็นผลิตภัณฑ์ประเภทเอนทิตี เอนทิตีพื้นฐานช่วยให้นักพัฒนาขยาย Drupal อย่างที่ไม่เคยคาดคิดจากนักออกแบบ Drupal ดั้งเดิม

เรื่องนี้ขึ้นอยู่กับการอภิปรายและในที่สุดคุณจะต้องตัดสินใจในฐานะนักพัฒนา

ฉันเลือกเอนทิตี้มากกว่าโหนดเมื่อใดก็ตามที่ข้อมูลไม่ควรเปิดเผยต่อสาธารณะด้วย URL ของตัวเอง โหนดจะได้รับค่าเริ่มต้นเป็นชื่อแทน URL, สถานะที่เผยแพร่, ชื่อ, เมตาแท็ก, ... ในขณะที่เอนทิตีเพิ่งได้รับการบันทึกในฐานข้อมูล

"ฉันต้องการที่จะเพิ่มแบนเนอร์พร้อมข้อความให้ได้มากที่สุดแล้วเลือกบล็อกอันใดอันหนึ่งใน blogpost"

• ประเภทเนื้อหาจะเป็น 'บล็อก'
• เอนทิตีที่กำหนดเองจะเป็น 'รายการแบนเนอร์'

เอนทิตีเทียบกับเนื้อหา

เอนทิตีมีการ รวมกลุ่มเอนทิตีที่มี ฟิลด์

เนื้อหาเป็นประเภทของเอนทิตี ดังนั้น,

เนื้อหามี การรวมกลุ่มเนื้อหา (บทความ, หน้า) ซึ่งมี ฟิลด์ (เนื้อหา, ภาพบทความ)

หากคุณเป็นโปรแกรมเมอร์คุณต้องเลือกเส้นทางในการสร้างเอนทิตีของคุณเอง แต่สำหรับผู้สร้างไซต์มันอาจไม่ใช่เส้นทางที่ดีที่สุด อีกครั้งสำหรับผู้สร้างไซต์มี UI สำหรับสร้าง Entity http://drupal.org/project/eck