Dengan status D8 saat ini, apa pohon keputusan untuk membuat tipe entitas konten baru versus membuat Tipe Konten untuk entitas konten "Node"?

Kami telah melihat empat tahun dan rilis pertama Drupal 8 sejak jawaban yang diterima ditulis untuk pertanyaan " Kapan tepat untuk membuat Entitas versus hanya menambahkan jenis konten baru ?" Dan, entitas lebih penting untuk Drupal 8 daripada di Drupal 7. ( RefB , RefC , RefD )

Di dunia Drupal 8 baru ini, apa pohon keputusan untuk membuat tipe entitas konten baru versus Tipe Konten baru untuk entitas konten tipe "Node"?

Saat Anda mempertimbangkan tanggapan, harap pertimbangkan yang berikut:

• Apakah Tipe Konten baru untuk tipe entitas konten "Node" masih sesuai dalam situasi 99% dibandingkan dengan tipe entitas konten baru?
• Apakah pohon keputusan sekarang menyertakan alasan yang lebih banyak, lebih baik, atau lebih jelas untuk menghindari penggunaan tipe entitas konten "Node" dan sebagai gantinya membuat tipe entitas konten baru? Dan jika ya, apakah mereka? Apakah mereka termasuk:
  • Performa?
  • Keamanan / izin?
  • Jumlah modul yang berfungsi dengan Tipe-entitas-tipe-Node dan tidak bekerja dengan tipe-entitas entitas konten lainnya?
• Mungkin - berdasarkan jawaban yang diterima sebelumnya yang direferensikan di atas - satu-satunya alasan umum untuk melakukan jenis entitas konten khusus adalah jika Anda ingin mengelompokkan data Node, mis. Dengan istilah taksonomi, atau membubuhi keterangan Node, misalnya dengan komentar?

Kompatibilitas modul sepertinya pertimbangan yang sangat menarik untuk pohon keputusan. Saat ini, beberapa modul yang paling terinstal memiliki rilis untuk 8.x yang tidak hanya alpha, beta, atau rc (kandidat rilis). Dan tampaknya sulit untuk mengidentifikasi berapa banyak dari mereka akan bekerja di luar kotak dengan tipe entitas kustom baru versus tipe konten Node-entitas baru. Tampaknya tidak ada atribut proyek untuk membedakan antara yang "ditulis untuk entitas" versus "ditulis untuk tipe konten entitas simpul".

Lihatlah pathauto, yang saat ini merupakan modul paling banyak diinstal keempat dari mereka yang memiliki segala jenis rilis 8.x. Orang-orang bekerja keras pada versi 8.x yang umumnya mendukung entitas dan bukan hanya Tipe Konten tipe entitas Node. Tetapi bagaimana dengan semua modul lainnya? Dan akankah modul yang mendukung entitas akan secara umum memerlukan tipe entitas konten khusus untuk memiliki "kait" khusus modul sebelum modul bekerja dengan mereka? (Lawan bagaimana modul dapat langsung bekerja di luar kotak dengan Jenis Konten baru?) Itu tampaknya merupakan jenis tantangan yang dihadapi oleh tim pathauto, dan mungkin itu merupakan alasan untuk menjauh dari jenis entitas konten khusus?

Mungkin juga layak disebutkan bahwa inti Drupal 8 berisi UI untuk membuat Tipe Konten baru untuk entitas konten tipe "Node", tetapi saat ini tidak mengandung UI untuk membuat tipe entitas konten baru. ( RefX , RefY , RefZ )

Pohon keputusan untuk memilih antara membuat Jenis Konten tipe entitas Node-baru versus jenis entitas konten baru:

1. Apakah Anda seorang programmer, atau apakah Anda memiliki akses mudah ke seorang programmer?
   • Jika tidak, maka saat ini Anda cukup banyak untuk membuat Jenis Konten Node-entitas baru. (Tidak ada UI pada intinya untuk membuat jenis entitas konten baru, dan modul kontribus Entity Construction Kit (ECK) saat ini hanya memiliki rilis alpha.)
   • Jika ya, maka lanjutkan ...
2. Apakah Anda tahu persis modul contrib mana yang ingin Anda manfaatkan untuk data Anda?
   • Jika tidak, maka taruhan aman mungkin hanya untuk membuat Tipe Konten Node-entitas.
   • Jika ya, apakah modul-modul itu sudah mendukung jenis entitas khusus yang Anda pertimbangkan, atau apakah Anda bersedia membantu meningkatkannya sehingga modul-modul itu akan atau membuat ulang fungsionalitas yang diinginkan dalam modul Anda?
     • Jika tidak, maka hanya membuat Tipe Konten Node-entitas-type mungkin yang terbaik untuk Anda.
     • Jika ya, maka lanjutkan ...
3. Akankah data konten aktual yang diaktifkan oleh modul Anda hanya membantu mengelompokkan atau membuat anotasi data konten lainnya? (Sehingga jarang dilihat sendiri.)
   • Jika ya, maka pertimbangkan apakah modul Anda seperti jenis entitas yang ada untuk istilah dan komentar taksonomi. Jika ya, maka jenis entitas baru mungkin merupakan taruhan yang aman.
   • Jika tidak, maka lanjutkan ...
4. Bisakah Anda mengartikulasikan dengan jelas mengapa Tipe Konten Node-entitas-tipe baru tidak akan bekerja untuk Anda?
   • Jika tidak, maka taruhan aman Anda adalah mungkin hanya membuat Tipe Konten Node-entitas-tipe baru.
   • Jika ya, maka lanjutkan ...
5. Terakhir, apakah Anda yakin bahwa Anda tidak bisa hanya memperluas tipe entitas-Node dan bahwa Anda ingin membuat ulang semua fungsi yang berguna seperti operasi CRUD?
   • Jika ya, silakan dan buat tipe entitas kustom baru.
   • Jika tidak, atau jika Anda tidak yakin, maka Anda mungkin ingin melibatkan beberapa ahli untuk membantu Anda memutuskan.

Catatan:

1. Pohon keputusan ini tidak mempertimbangkan kinerja atau keamanan. Saya tidak yakin apakah atau kapan tipe entitas konten kustom baru akan berkinerja lebih baik dan lebih atau kurang aman daripada tipe entitas-Node.
2. Bahkan jika pohon ini adalah jawaban yang baik, itu mungkin tidak akan tetap satu dari waktu ke waktu karena pembaruan dalam Drupal core dan rilis modul contrib. StackExchange tampaknya tidak mengakomodasi bagaimana jawaban "terbaik" hari ini mungkin bukan jawaban terbaik besok.)

Pendekatan sederhana tentang masalah itu adalah dengan mempertimbangkan tujuan proyek, ukuran dan persyaratan bisnis.

1. Bagaimana tipe konten simpul-entitas default memengaruhi pembangunan proyek dengan cara yang mudah dan rapi, lebih dekat dengan arsitektur dan aliran data yang dihasilkan dari pemikiran analitik dokumen proyek.

Pemberitahuan penting di sini keputusan membuat jenis entitas baru biasanya diambil oleh pengembang atau arahan teknis bukan pembangun situs atau pemilik proyek yang mengelola aplikasi dan hanya fokus pada bisnis.

2. Drupal 8 tergantung pada beberapa paket symfony2 dan lebih dekat dengan kerangka kerja, pengembangan yang berbicara tentang cm tradisional dengan Drupal dengan perubahan arsitektur besar, saya membayangkan membangun entitas baru lebih baik daripada melakukan banyak penyesuaian dan konfigurasi kompleks pada tipe konten node-entitas agar untuk memanfaatkan Drupal di antara kerangka kerja lainnya karena banyak orang tidak menyukai cara konfigurasi Drupal dan pengaturan yang didistribusikan, Anda mungkin menghadapi beberapa orang yang berasal dari WordPress dan digunakan untuk mengonfigurasi setiap hal dari satu bentuk yang membuat mereka terganggu ketika berhadapan dengan dasbor admin Drupal.

3. Drupal 9 berencana untuk benar-benar menghapus sistem hook dan menggantikannya dengan event dispatcher yang mengarah pada kebutuhan besar untuk antarmuka admin untuk membuat entitas baru karena mengubah fungsi yang ada dari kode akan jauh lebih sulit untuk orang yang bukan pengembang dan akan sangat penting untuk tambahkan fitur itu.

Pada akhirnya , saya melihat entitas baru yang dirancang untuk kebutuhan proyek memberikan kinerja tinggi lebih baik daripada tipe konten kompleks dengan sejumlah besar bidang karena kami sekarang setiap bidang menambahkan 2 tabel ke DB dan perlu memuat konfigurasi pada setiap permintaan, terutama dengan logika bisnis berat diperlukan.

Polos dan sederhana: Tidak semua konten. Daftar konten bisa sangat panjang dan membingungkan jika Anda hanya menggunakan tipe konten. ( ContentEntityBase juga dapat diimplementasikan oleh entitas kustom thoe)

Jika Anda memiliki penulis dan status publikasi, Anda harus menggunakan jenis konten.

Kalau tidak (mengasumsikan seorang programmer Anda) entitas kustom harus lebih disukai. Banyak yang dapat dengan mudah diimplementasikan dengan semua antarmuka (seperti yang bisa direvisi, yang bisa di lapangan, pembatasan akses, dll.)

Dalam pandangan saya ini hanya arsitektur yang lebih jelas dan berurutan (dan juga lebih banyak performan).

Memikirkan reusability dalam beberapa proyek upaya untuk membuat entitas kustom meledak .. ada juga banyak pembantu seperti drupal-code-generator . Untuk menjaga pengkodean (atau kompleksitas) kustom pada level rendah, Anda harus mempertimbangkan untuk menggunakan tipe konten jika Anda ingin:

• Untuk menerjemahkan 'entitas' (setidaknya dalam D7), akan ada juga antarmuka.
• (terbuka untuk saran) ..

Ini adalah pertanyaan sulit yang menurut saya jujur ​​hanya dipahami setelah Anda menerapkannya sebelumnya. Tetapi sebagai remy metioned, tidak semuanya mentah, pengguna menghadapi konten .

Di Drupal 7, kemampuan membuat entitas kustom ada, tetapi bisa menjadi tugas yang menakutkan jika Anda kasar di tepinya dengan OOP. Itu semacam setengah diimplementasikan (atau setengah dilakukan, namun Anda ingin mengatakannya), yang mengarah pada cara menciptakan entitas yang tidak semuanya sama persis dan pendekatan yang disepakati, dengan prosedur campuran dan OOP campuran.

Di Drupal 8, idenya jauh lebih terwujud, dan jauh lebih mudah untuk bangun dan berjalan dengan entitas kustom. Node sendiri didasarkan pada ContentEntityBase, seperti Blok, Pengguna, File, dan Taksonomi.

Node khusus untuk data konten yang dipublikasikan, terlihat (atau resmi) yang biasanya bertindak sebagai konten (yaitu, dalam menu, atau dalam sitemap, atau xml sitemap, atau RSS feeds, dll). Drupal dirancang sedemikian rupa agar Anda dapat terhubung ke setiap langkah proses operasi simpul dan mengubahnya yang dapat memiliki konsekuensi yang tidak diinginkan jika Anda memiliki campuran modul kontribusi yang salah. Ini mungkin pendapat yang kontroversial, tetapi membantu menceraikan diri Anda sendiri dari gagasan "semuanya adalah simpul" untuk lebih merangkul konsep Entity.

Konten ideal yang menghasilkan tipe konten hebat:

• Artikel
• Halaman
• Posting pekerjaan
• Peristiwa
• Halaman arahan
• Beranda

Utas umum bagi mereka adalah bahwa mereka berbagi konsep jenis konten. Biasanya dalam sejumlah negara alur kerja (diterbitkan, dipromosikan, lengket, diarsipkan, ditampilkan, dll - jika Anda menggunakan opsi penerbitan kustom), dan sejumlah besar modul berkontribusi berinteraksi secara langsung, seperti Pathauto.

Tetapi mari kita asumsikan Anda ingin menyimpan data dalam Drupal yang internal, pribadi, mendorong data lain, atau data yang seharusnya tidak memungkinkan integrasi di luar ruang lingkupnya kecuali Anda mengizinkannya. Data seperti apa ini? Berikut beberapa jenis yang mungkin:

• Produk (Perdagangan Drupal)
• Item Baris (Perdagangan Drupal)
• Server pencarian (ApacheSolr / SearchAPI)
• Kontak (seperti lead CRM)
• Tiket (seperti tiket dukungan)

Apa yang membuat ini sangat berbeda? Mengapa Anda menginginkan entitas untuk kontak, alih-alih menggunakan model Pengguna? Anda dapat membuat beberapa argumen di sana, tetapi contoh saya adalah bahwa jika Anda mengatakannya, mengumpulkan alamat dan nama email dan beberapa data meta lainnya dari formulir kontak, simpan data itu sebagai entitas kustom. Anda mencegah daftar pengguna agar tidak tercemar dengan barang-barang non-akun, Anda mengurangi potensi masalah keamanan (bagaimana jika skrip atau seseorang secara tidak sengaja memperbarui akun tersebut menjadi admin atau mengirim surat massal?), Anda membuat manajemen overhead internal pengguna yang sebenarnya akun lebih mudah, dan Anda mengelompokkan apa yang Anda tangkap ke apa itu, sedikit data khusus.

Dari sini, sebagian besar bercerai dari bagian yang lebih otomatis dari sistem Drupal / Node dan Anda dapat menyesuaikan tindakan dan pengalaman. Anda menentukan rute, akses, dan alur kerja CRUD.

Dalam pola pikir itu, membuatnya lebih mudah untuk melihat mengapa pendekatan untuk itu akan dilakukan dengan cara itu. Ambil contoh tiket dukungan - ini adalah permintaan masuk, tetapi bukan data yang dipublikasikan, dan kemungkinan memiliki alur kerja yang sangat spesifik yang lebih mudah untuk mengatur jalan Anda daripada menceraikannya dari bagian-bagian dari sistem simpul yang tidak ingin Anda patuhi untuk.

Contoh lain adalah data eksternal yang diimpor. Dalam kebanyakan kasus, data ini biasanya tidak diperkaya dengan data Drupal lokal (bahkan jika itu, sebagai suatu entitas, Anda masih bisa melakukannya). Itu bisa apa saja. Mungkin fakturnya, mungkin buku, mungkin menarik merek bir.

Data seperti ini biasanya spesifik dan membutuhkan kontrol di luar apa yang dimaksudkan untuk node. Itu bukan untuk mengatakan bahwa Anda tidak dapat menambahkannya dengan menggunakan bidang referensi pada simpul untuk menunjuk ke entitas kustom Anda (ini adalah cara Drupal Commerce bekerja, pada tingkat tertentu) untuk memperkaya data. Pada saat yang sama, Anda mengisolasi dan memastikan kontrol atas data dan UI Anda dari kode kontribusinya melampaui desain dan mengganggu model Anda. Ini kemungkinan kurang dari masalah di D8 daripada di D7, meskipun beberapa kait tetap.

Arsitektur yang tepat sekarang ada untuk mendorong pemisahan. Tidak semuanya merupakan simpul.