ฉันสงสัยว่าจะตัดสินใจใช้โมดูลหลัก Taxonomy หรือโมดูลอ้างอิงเอนทิตีได้อย่างไร

ฉันไม่ได้ใช้โมดูลการอ้างอิงเอนทิตีมาก่อน แต่ฉันเคยใช้โมดูลอนุกรมวิธาน (และบางโมดูลที่เกี่ยวข้อง) ในเว็บไซต์ 10-15 แห่ง

อะไรคือข้อดีหรือข้อเสียของการใช้โมดูลอ้างอิงตามแทนโมดูลอนุกรมวิธาน?

เมื่อเร็ว ๆ นี้ฉันเริ่มสร้างเว็บไซต์เก็บถาวรของนิตยสาร

มีนิตยสารมากมาย นิตยสารเหล่านี้มีปัญหา แต่ละประเด็นมีบทความ

ที่เล็กที่สุด (และที่ลึกที่สุด) ส่วนนี่เป็นบทความ

บทความ

• หมายเลขหน้า (ช่วง):
• หัวข้อ:
• ผู้แต่ง:
• ประเภทบทความ:
• คำสำคัญ:
• นิตยสาร:
• ปัญหา:

ปัญหา

• หมายเลขการออก:
• รูปภาพหน้าปก:
• วันที่ (เผยแพร่):
• นิตยสาร:

นิตยสาร

• รายละเอียด:
• รูปภาพหน้าปก:

ที่นี่มี (อย่างน้อย) 2 วิธีในการติดตั้งเว็บไซต์นี้:

1.จะมีประเภทเนื้อหาที่เรียกว่าarticleและอื่น ๆ ทั้งหมด (ฉบับ, นิตยสาร, ผู้แต่ง) จะเป็นคำศัพท์ทางอนุกรมวิธาน (ลำดับชั้น) จะมีลำดับชั้นระหว่างปัญหากับนิตยสารเป็นต้น

2.จะมีเนื้อหาหลายประเภท: บทความ, ปัญหา, นิตยสาร, ผู้แต่ง ในขณะที่สร้างบทความ ปัญหานิตยสารและผู้แต่งสามารถอ้างอิงได้ ฯลฯ

ในทางทฤษฎีแล้วทั้งสองวิธีดูเหมือนกันมาก

มีใครบ้างที่ประสบสถานการณ์คล้ายกันและคุณช่วยบอกวิธีที่คุณชอบได้ไหม

นอกจากนี้ยังมีวิธีแก้ไขปัญหาอื่น ๆ สำหรับปัญหาของคุณ

การรวบรวมสนาม

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

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

เอนทิตีดูสิ่งที่แนบมา

หรือที่เรียกว่าโมดูลEVA

"Eva" ย่อมาจาก "Entity Views Attachment;" มันมีปลั๊กอินการแสดงผลมุมมองที่ช่วยให้การส่งออกของมุมมองที่จะแนบไปกับเนื้อหาของเอนทิตี Drupal ใด ๆ เนื้อความของโหนดหรือข้อคิดเห็นโปรไฟล์ของบัญชีผู้ใช้หรือหน้ารายการสำหรับคำ Taxonomy เป็นตัวอย่างทั้งหมดของเนื้อหาเอนทิตี

คุณสามารถใช้ EVA เพื่อแสดงเฉพาะค่าฟิลด์สำหรับเนื้อหาบางส่วนทำให้สามารถควบคุมการแสดงผลและการจัดรูปแบบความยืดหยุ่นของฟิลด์ได้อย่างเหลือเชื่อ ตัวอย่างเช่นคุณอาจต้องการให้มีสองเขตข้อมูลที่ต่อกันด้วยวิธีพิเศษบางอย่าง คุณสามารถเพิ่มเขตข้อมูลของคุณลงในจอแสดงผล EVA ของคุณตั้งค่าตัวกรองเชิงบริบทเป็น NID เพิ่มส่วนกลาง: ฟิลด์ข้อความและการใช้โทเค็นจัดรูปแบบเขตข้อมูลของคุณด้วย HTML อย่าลืมที่จะยกเว้นเขตข้อมูลของคุณจากการแสดงถ้าคุณจะใช้พวกเขาร่วมกันในส่วนกลาง: เขตข้อมูลข้อความ ตัวอย่าง: คุณอาจมีเขตเมืองรัฐและรหัสไปรษณีย์ คุณสามารถรวมไว้ในส่วนกลาง: ฟิลด์ข้อความในมุมมองเพื่อแสดงเป็น "เมือง, รัฐไปรษณีย์" เมื่อคุณจัดการจอแสดงผลสำหรับประเภทเนื้อหาของคุณให้เพิ่ม EVA ที่เพิ่งสร้างไปยังจอแสดงผลและเมื่อใดก็ตามที่โหนดประเภทนั้นปรากฏขึ้นมันจะผ่าน nid ไปยัง EVA และ EVA จะส่งคืนฟิลด์ที่คุณเลือก จัดรูปแบบตามที่คุณต้องการ (ที่มา:กรณีการใช้ข้อมูลอ้างอิง EVA และ Entity วิธีการ )

โมดูลนี้สมบูรณ์แบบมันแนบดูเป็นเขตข้อมูลไปยังโหนดของประเภทเนื้อหา Albumผมใช้โมดูลนี้จะสร้าง อัลบั้มประกอบด้วยsinger(มีข้อมูลเกี่ยวกับแต่ละรายการ) และsongsประกอบด้วยไฟล์ชื่อเรื่องอัตราและ ... ดังนั้นฉันจึงสร้าง View of type EVAและฉันแนบมันไปยังโหนด ดังนั้นในหน้าโหนดของนักร้องทุกคนฉันแสดงมุมมองนี้ซึ่งได้รับข้อมูลที่เหมาะสมจากโหนด การอ้างอิง Views with Entityเป็นบทช่วยสอนที่สมบูรณ์แบบเกี่ยวกับวิธีการใช้โมดูลนี้

Taxonomy Terms VS Entity Reference

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

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

ถึงแม้ว่า Taxonomy นั้นใช้งานง่าย แต่ฉันเองก็ชอบ Entity Reference มาก แต่ก็เปิดโอกาสและความสามารถในการปรับขยายได้มากมายและช่วยให้สามารถสร้างโครงสร้างที่ซับซ้อนมากได้ แนวคิดของเอนทิตีในบริบทนี้ไม่ จำกัด เฉพาะเนื้อหา มันสามารถแสดงความคิดเห็นผู้ใช้ taxonomies และ ... มันเป็นมากขึ้นปรับขนาดได้ดังนั้นคุณจะไม่ต้องกังวลเกี่ยวกับการปรับแต่งประเภทเนื้อหาหรือการปรับเปลี่ยนในอนาคต (มันก็ชี้ให้เห็นในEntity อ้างอิงกับอนุกรมวิธาน ) ฉันเชื่อว่าวิธีการของเอนทิตี้มีประสิทธิภาพมากกว่าอนุกรมวิธาน

นอกจากนี้ยังมีชุดค่าผสมอื่น ๆ ของวิธีการเหล่านี้ซึ่งไม่จำเป็นต้องพูดถึง

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

คุณอาจมีชุดค่าผสมอื่น ๆ เช่นบทความและปัญหาคือโหนดที่นิตยสารจัดทำภาษี

ไม่มีคำตอบที่ถูกหรือผิดสำหรับเรื่องนี้ แต่ขึ้นอยู่กับความชอบส่วนตัวข้อกำหนดของโครงการที่เฉพาะเจาะจง ฯลฯ

เป็นการดีที่สุดที่จะใช้โหนดสำหรับเนื้อหาและ taxonomies สำหรับการจัดหมวดหมู่ของเนื้อหานั้นอย่างไรก็ตามบางครั้งมันอาจมืดมัวไปเล็กน้อย

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

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

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

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

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

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

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

คุณอาจพบว่าหากคุณย้ายไปใช้ประเภทเอนทิตีอื่น ๆ เช่นโหนดที่มี entity_reference คุณจะไม่มีปัญหาในการเปลี่ยนแปลงเนื่องจากทุกอย่างทำงานในลักษณะเดียวกัน แต่จะให้ความยืดหยุ่นมากกว่า

ฉันจะไม่พูดว่านี่เป็นคำตอบที่ถูกต้องที่สุด แต่เป็นวิธีที่ฉันคิดเกี่ยวกับมัน ฉันจะอธิบายด้วยตัวอย่าง

ฉันมักจะใช้ taxonomies เพื่อจัดหมวดหมู่โหนดขึ้นอยู่กับสิ่งที่เป็นนามธรรม ตัวอย่างเช่นข่าวสามารถแบ่งออกเป็นกีฬาการเมืองและอื่น ๆ

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

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

ฉันแน่ใจว่ามีคนถามว่าทำไมฉันจะอยู่ห่างจากคอลเลกชันฟิลด์ แต่ความคิดเห็นดูเหมือนจะถูกลบออก วิธีทั้งสองเซ็นต์ของฉัน:

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

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

ในกรณีนี้หากนิตยสารของคุณมีเนื้อหา (คำอธิบายของมันคืออะไรรายละเอียดเกี่ยวกับการสั่งซื้อ ฯลฯ ) หรือ "หน้า" ของมันเองควรเป็นประเภทเนื้อหาเนื่องจากเป็นเนื้อหา

ปัญหามีความคลุมเครือเล็กน้อย แต่คุณก็มีโอกาสที่จะได้ภาพรวมและอื่น ๆ ดังนั้นพวกเขาจึงน่าจะมีหน้าและมีเนื้อหาเหมือนกัน ดังนั้นเนื้อหาประเภทอื่น

บทความเป็นประเภทเนื้อหาที่เห็นได้ชัด

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

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

ฟอร์มเอนทิตีแบบอินไลน์ช่วยให้คุณสร้างและแก้ไขเอนทิตีที่อ้างอิงจากภายในเอนทิตีที่คุณต้องการอ้างอิงจาก ... ดังนั้นสร้าง / แก้ไขผู้เขียนจากภายในบทความหรือเพียงแค่อ้างอิงที่สร้างขึ้นแล้ว

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

วงกลมกลับไปสู่ ​​taxonomies คุณจะใช้สิ่งเหล่านี้กับ "แท็ก" บทความอื่น ๆ ด้วย ... "การตกปลา", "รถยนต์", "คอมพิวเตอร์" ฯลฯ / อะไรก็ตาม ... เพื่อให้คุณสามารถค้นหาปัญหานิตยสารบทความ หรือผู้แต่งที่มีเนื้อหา / เขียนเกี่ยวกับแท็กนั้น

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