Mevcut D8 statüsünde, “Düğüm” içerik varlığı için bir İçerik Türü yaratmaya karşı yeni bir içerik varlık türü yaratma karar ağacı nedir?

Kabul edilen cevabın " Yeni bir içerik türü eklemeye karşı bir Varlık oluşturmak ne zaman uygundur ?" Sorusu için yazıldığından beri dört yıl ve Drupal 8'in ilk yayınını gördük. Ve işletmeler Drupal 8 için Drupal 7’dekinden daha merkezidir . ( RefB , RefC , RefD )

Bu yeni Drupal 8 dünyasında, "Node" türündeki içerik varlığı için yeni bir İçerik Türü ile karşılaştırıldığında yeni bir içerik varlık türü yaratma konusundaki karar ağacı nedir?

Yanıt almayı düşündüğünüz için, lütfen aşağıdakileri göz önünde bulundurun:

• "Node" içerik varlık tipi için yeni bir İçerik Türü, yeni bir içerik varlık tipine karşı% 99 durumlarda hala uygun mudur?
• Karar ağacı şimdi "Düğüm" içerik varlık türünü kullanmaktan kaçınmak ve bunun yerine yeni bir içerik varlık türü oluşturmaktan daha fazla, daha iyi veya daha net nedenler içeriyor mu? Ve eğer evet ise, bunlar nedir? Bunlar şunları içeriyor mu:
  • Performans?
  • Güvenlik / izinler?
  • Düğüm-varlık tipi İçerik Türleriyle çalışan ve diğer içerik varlık türleriyle çalışmayan modüllerin sayısı?
• Belki de - yukarıda referans verilen önceki kabul edilen cevaba göre - özel içerik varlık türünü yapmanın tek genel nedeni, örneğin taksonomi terimleriyle veya başka bir şekilde, örneğin yorumlarla Düğüm verilerini gruplandırmak mı istiyorsunuz?

Modül uyumluluğu, karar ağacı için özellikle ilginç bir husus gibi görünüyor. Şu anda, en çok kurulu modüllerin birçoğunun 8.x için yalnızca alfa, beta veya rc olmayan bir sürüm sürümü var (sürüm adayı). Ve bunların birçoğunun yeni Node-entity içerik türüne karşı yeni bir özel varlık tipiyle hazır bulunmayacağını belirlemek zor görünüyor. "Varlıklar için yazılmışlar" ile "düğüm varlıkları içerik türleri için yazılmışlar" arasında ayrım yapmak için bir proje niteliği olduğu görülmemektedir.

Şu anda herhangi bir 8.x sürümüne sahip olanların dördüncü en yüklü modülü olan pathauto'ya bir göz atın. Millet, yalnızca Düğüm türü türdeki İçerik Türlerini değil, genel olarak varlıkları destekleyen 8.x sürümlerinde çok çalışıyor . Peki ya diğer tüm modüller? Ve varlıkları destekleyen modüller, genellikle modül onlarla çalışmadan önce modüle özel "kancalara" sahip olmak için genellikle özel içerik varlık türlerini gerektirecek mi? (Modüllerin kutudan yeni İçerik Türleriyle nasıl başa çıkabildiğine karşı ?) Pathauto ekibinin birlikte çalıştığı zorluklar gibi görünüyor ve belki de özel bir içerik varlık türünden uzaklaşmak için bir neden olabilir mi?

Drupal 8 çekirdeğinin, "Node" türündeki içerik varlığı için yeni İçerik Türleri oluşturmak için bir kullanıcı arayüzü içerdiğini belirtmek faydalı olabilir, ancak şu anda yeni içerik varlık türleri oluşturmak için bir kullanıcı arabirimi içermemektedir. ( RefX , RefY , RefZ )

Yeni bir içerik varlık türü ile yeni bir Düğüm-varlık tipi İçerik Türü oluşturmak arasında seçim yapmak için karar ağacı:

1. Programcı mısınız, yoksa programcıya kolay erişebiliyor musunuz?
   • Hayır ise, o zaman şu anda yeni Düğüm Varlığı İçerik Türleri oluşturmakla sınırlısınız. (Yeni içerik varlık türleri oluşturmak için temelde bir kullanıcı arayüzü yok ve Varlık Yapı Kiti (ECK) modülü şu anda yalnızca bir alfa sürümüne sahip.)
   • Eğer öyleyse, devam et ...
2. Verileriniz için hangi katkı modüllerinden yararlanacağınızı biliyor musunuz ?
   • Hayır ise, o zaman güvenli bahis muhtemelen sadece bir Node-varlık İçerik Türü oluşturmaktır.
   • Evetse, bu modüller zaten düşündüğünüz özel varlık türlerini destekliyor mu, yoksa modülünüzde istenen işlevselliği yeniden oluşturacak veya yeniden oluşturacak şekilde onları geliştirmeye yardım etmek istiyor musunuz?
     • Hayır ise, sadece bir Node-varlık tipi İçerik Türü oluşturmak sizin için en uygun olabilir.
     • Eğer öyleyse, devam et ...
3. Modülünüz tarafından etkinleştirilen gerçek içerik verileri yalnızca diğer içerik verilerinin gruplanmasına veya açıklanmasına yardımcı olur mu? (Böylece nadiren kendi başına görülecektir.)
   • Evetse, modülünüzün taksonomi terimleri ve yorumları için var olan varlık türleri gibi olup olmadığını düşünün. Öyleyse, yeni bir varlık türü güvenli bir bahis olabilir.
   • Hayır ise, devam et ...
4. Yeni bir Düğüm-varlık tipi İçerik Türünün sizin için neden işe yaramayacağını açıkça söyleyebilir misiniz?
   • Eğer hayır ise, güvenli bahisiniz muhtemelen sadece yeni bir Düğüm tipi içerik Türü oluşturmaktır.
   • Eğer öyleyse, devam et ...
5. Son olarak, Düğüm-varlık türünü yalnızca genişletemediğinizden ve CRUD işlemleri gibi tüm kullanışlı işlevlerini yeniden oluşturmak istediğinizden emin misiniz?
   • Evetse, devam edin ve yeni bir özel varlık türü oluşturun.
   • Eğer hayırsa veya emin değilseniz, o zaman muhtemelen karar vermenize yardımcı olacak bazı uzmanlarla bağlantı kurmak istersiniz.

Notlar:

1. Bu karar ağacı performans veya güvenliği dikkate almaz. Yeni bir özel içerik varlık türünün bir Node-varlık türü türünden daha iyi veya daha az performans gösterip göstermeyeceğinden emin değilim.
2. Bu ağaç iyi bir cevap olsa bile, Drupal çekirdeğindeki güncellemeler ve modül sürümlerine katkıda bulunma nedeniyle büyük olasılıkla zaman içinde kalmayacak. StackExchange bugün "en iyi" cevabının yarın en iyi cevabı olamayacağına benzemiyor.)

Bu konuda basit bir yaklaşım , projenin amacını, büyüklüğünü ve iş gereksinimlerini dikkate almaktır.

1. Nasıl düğüm-varlık içerik türü daha yakın mimari ve proje dokümanlar analitik düşünme üretilen verilere akar için kolay, düzgün bir şekilde projeyi inşa etkileyen varsayılan.

Buradaki önemli bir not , yeni varlık türü yaratma kararının, genellikle uygulamayı oluşturan ve yalnızca işe odaklanan site üreticileri veya proje sahipleri değil geliştiriciler veya teknik yönlendiriciler tarafından alındığı yönündedir.

2. Drupal 8 , bazı symfony2 paketlerine bağlıdır ve çerçevelere, geleneksel cms’in bu büyük mimari değişikliklerle bahsettiği geleneksel cms’lerin konularına daha yakın olduğunu düşünüyorum. Birçok kişi Drupal konfigürasyonunu ve dağıtılmış ayarları sevmediği için Drupal'ı diğer çerçeveler arasında kullanmak, bazı kişilerin WordPress'ten geldiğini ve Drupal yönetici gösterge panosu ile uğraşırken kendilerini rahatsız eden tek bir formdan yapılandırmak için kullanılabileceğini görebilirsiniz.

3. Drupal 9, kanca sistemini tamamen kaldırmayı ve yönetici işlevselliğine yeni bir varlık oluşturma ihtiyacını doğuran olay göndericiyle değiştirmeyi planlıyor, çünkü mevcut işlevselliği koddan değiştirmek, geliştirici olmayan insanlar için çok daha zor olacak ve bu özelliği ekle.

Sonunda, proje ihtiyaçları için uyarlanmış yeni varlıkların, çok sayıda alan içeren karmaşık içerik türlerinden daha yüksek performans sağladığını görüyorum, çünkü şu anda her bir alan DB'ye 2 tablo ekliyor ve konfigürasyonunu her istek üzerine, özellikle ağır iş mantığı gerekli.

Sade ve basit: Hepsi içerik değil. İçeriğin listesi oldukça uzayabilir ve yalnızca içerik türleri kullanıyorsanız kafa karıştırıcı olabilir. ( ContentEntityBase ayrıca özel bir kuruluş tarafından da uygulanabilir)

Bir yazarınız ve yayınlanmış bir durumunuz varsa, bir içerik türü aramalısınız.

Aksi takdirde (bir programcınız varsayarsak) özel varlıklar tercih edilmelidir. Tüm arayüzler (revizyon yapabilen, sahaya uygun, erişim kısıtlaması gibi) ile kolayca uygulanabilir.

Benim görüşüme göre bu sadece daha açık ve kuyruklu mimarisi (ve ayrıca daha performans).

Birkaç projede yeniden kullanılabilirliği düşünmek, kişisel varlıkların havaya uçurulması için çaba sarf ediyor. Ayrıca drupal kod üreteci gibi hoş yardımcılar da var . Özel kodlamayı (veya karmaşıklığı) düşük seviyede tutmak için, isterseniz içerik türlerini kullanmayı düşünmelisiniz:

• 'Varlığı' çevirmek için (en azından D7 de), bir arayüz de olacaktır.
• (önerilerinize açık) ..

Dürüst olmak gerekirse, daha önce uyguladığınızda sadece anlaşıldığını düşündüğüm zor bir soru. Ancak remy'nin söylediği gibi, her şey ham değil, kullanıcının karşı karşıya olduğu içeriktir .

Drupal 7'de, özel varlıklar yaratma kabiliyeti vardı, ancak OOP ile birlikte kenarlarda kaba olsaydınız göz korkutucu bir iş olabilirdi. Karma usul ve karma OOP ile tamamen tek tip ve yaklaşımlar üzerinde anlaşmaya varmayan varlıklar yaratma yollarına yol açan, yarısı uygulandı (veya yarısı yapıldı, ancak bunu söylemek istiyorsunuz).

Drupal 8'de, fikir çok daha farkedilmiştir ve özel bir varlık ile kalkmak ve çalıştırmak çok daha kolaydır. Düğümün kendisi, Blocks, Kullanıcılar, Dosya ve Taksonomi gibi ContentEntityBase'e dayanır.

Düğümler olan özellikle tipik içerik olarak hareket yayınlanan içeriği görünür (veya yetkili) veriler için (olduğunu, bir menüde veya site haritasının, veya xml site haritasına veya RSS beslemeleri, vb). Drupal, düğüm işlemlerinin herhangi bir adımına bağlanabileceğiniz ve katkıda bulunan modüllerin yanlış bir karışımını varsa istenmeyen sonuçları doğuracak şekilde değiştirebileceğiniz şekilde tasarlanmıştır. Bu muhtemelen tartışmalı bir düşüncedir, ancak Varlık kavramını daha fazla kucaklamak için kendinizi "her şey bir düğümdür" fikrinden uzaklaştırmaya yardımcı olur.

Mükemmel içerik türleri yapan ideal içerik:

• makale
• Sayfa
• İş ilanı
• Etkinlik
• Açılış sayfası
• Anasayfa

Onlara ortak olan konu, bir tür içerik kavramını paylaşmalarıdır. Genellikle herhangi bir sayıda iş akışı durumundadır (yayınlanmış, tanıtılmış, yapışkan, arşivlenmiş, özellikli vb. - özel yayınlama seçenekleri kullanıyorsanız) ve katkıda bulunan çok sayıda modül Pathauto gibi doğrudan etkileşimde bulunur.

Ancak, Drupal'da dahili, gizli, diğer verileri ya da izin vermediğiniz sürece kapsamı dışında entegrasyona izin vermemesi gereken verileri saklamak istediğinizi varsayalım. Bu ne tür bir veri olabilir? İşte bazı olası türler:

• Ürün (Drupal Ticaret)
• Satır Öğesi (Drupal Commerce)
• Arama sunucusu (ApacheSolr / SearchAPI)
• İletişim (CRM müşteri adayı gibi)
• Bilet (destek bileti gibi)

Bunları bu kadar farklı kılan nedir? Kullanıcı modelini kullanmak yerine neden iletişim için bir varlık istiyorsunuz? Orada birkaç argüman yapabilirsiniz, ancak benim örneğim, bir e-posta adresi ve adlarını ve bir diğer formdan bir iletişim formundan veri toplamak olduğunu söylerseniz, bu verileri özel bir varlık olarak saklamak olur. Kullanıcı listesinin hesap dışı öğelerle kirlenmesini önlüyorsunuz, olası güvenlik sorunlarını azaltıyorsunuz (bir komut dosyası veya bir kişi yanlışlıkla bu hesapları yöneticiler olmak üzere ya da toplu postalar göndermek için güncellerse?) hesapları daha kolay hale getirir ve yakaladığınız şeyi ne olduğuna, özel bir veri parçasına göre bölümlere ayırırsınız.

Buradan, Drupal / Node sisteminin daha otomatik kısımlarından büyük ölçüde boşanır ve eylemleri ve deneyimleri uyarlayabilirsiniz. Rotaları, erişimi ve CRUD iş akışını siz belirlersiniz.

Bu zihniyette, buna yaklaşımın neden bu şekilde yapıldığını görmeyi kolaylaştırır. Destek bileti örneğini alın - gelen isteklerdir, ancak yayınlanmış veriler değildir ve büyük olasılıkla çok kolay bir iş akışına sahiptir, bu da yolunuzu kurmanızın, düğüm sisteminin bağlı kalmasını istemediğiniz parçalardan ayırmaktan daha kolaydır. için.

Başka bir örnek, dışa aktarılan veri olabilir. Çoğu durumda, bu veriler genellikle yerel Drupal verileriyle zenginleştirilmez (varlık olarak, yine de yapabilirsiniz). Her şey olabilir. Belki faturalar, belki onlar kitap, belki de bira markaları çekiyor.

Bunun gibi veriler genellikle spesifiktir ve düğümün ne anlama geldiğinin ötesinde kontrol gerektirir. Bu, özel varlığınıza (Drupal Commerce'in bir düzeyde nasıl çalıştığını) işaret etmek için düğümdeki bir referans alanını kullanarak bunu genişletemeyeceğinizi söylemek değildir. Aynı zamanda, verileriniz ve UI'nız üzerinde kontrolü kontrol altına alıyor ve tasarımınızın ötesine geçerek modelinize müdahale ediyor. Bazı kancaların kalmasına rağmen, bu muhtemelen D8'de D7'de olduğundan daha az sorun yaratıyor.

Uygun mimari şimdi ayrılığı teşvik etmek için var. Her şey bir düğüm değildir.