Yanıtlar:
Faydaların ne olduğu hakkında çok fazla bir şey değil, söylediğiniz gibi belirli bir durum için neyin uygun olduğu hakkında daha fazlası. Düğümlü hemen hemen her şeyi temsil edebilirsiniz ve durumların% 99'unda (en azından bulduğum gibi) özel varlık türlerini uygulamanız gerekmez.
taxonomy_termVarlık türünü her zaman neden her şeyin bir düğüm / içerik türü olmamasının iyi bir örneği olduğunu düşünüyorum :
Bir taksonomi terimi temel olarak farklı varlıkları birlikte gruplamak içindir ve bu nedenle bir düğüm ile aynı işlevselliği gerektirmez. Eğer iken olabilir teorik olarak (belki bir düğüm referans alanıyla) bu işlevselliği gerçekleştirmek için bir içerik türü kullanmak gerçekten bunu yapmak için mantıklı değildir bu yüzden, bir sınıflandırma terimi bir düğüm olarak aynı şeyi yapmak zorunda değildir. Aynı userve taxonomy_vocabularyvarlık türleri için söylenebilir .
Dolayısıyla, bir taksonomi terimi ayrı bir varlık olarak yaratılır ve alanların eklenmesi vb. Gibi avantajlardan yararlanırken, yalnızca ihtiyaç duyduğu şeyi yapmak üzere programlanır.
Ben basit bir cevabı bir düğüm / içerik türü ne zaman olduğunu düşünüyorum gelmez size ihtiyacınız veya çok az yararı için overkill / yükü sadece büyük bir miktar olanı yapmak, o zaman özel bir varlık yazmayı tercih etmelisiniz.
Bu sadece kişisel deneyimime dayanıyor; Drupal çekirdek gelişimine doğrudan katılan birisinin bu konuda ne söylediğini duymak isterim.
Kullandığım çok basit bir kural, içeriğinizin genel olarak tek başına gösterilmesi gerekip gerekmediğidir. Öyleyse, bir varlık seçmiyorsanız, düğüme gidin. Varlık formları artık varlıklarınızı doldurmak için bir arayüz oluşturmanıza olanak sağlar.
Örneğin, D6 ile yapılan bir web sitesinde bir reklam içeriği türü (resim alanı, başlangıç / bitiş tarihi ... ile birlikte) oluştururuz, ancak daha sonra bunu varsayılan olarak yayınlamamalı ve editörünüze düzenleme hakkı vermelisiniz. / bu düğümü görüntüle ve hiçbir görüş / aramanın dış dünyada bunları göstermeyeceğini umuyordum. Oldukça hantal ve varlıklarla uğraşmak daha kolay olurdu.
Bir işletme, belirli bir kullanım durumunu temsil eder .
Bu basit tanımın kredisinin Fago'ya gittiğine inanıyorum , fakat referans bulmak için tembelim.
Biz kullanabilirsiniz Content(aka Nodesbiz istiyorsa tüm kullanım senaryoları için), ama çoğu zaman o mantıklı değil.
Content yorum ve menü konumu için bir yazarı ve ayarları var.
Users, her ikisinden de yeterince farklı olan bir kullanım durumunu temsil eder, Contentçünkü useryukarıdakilerin hiçbiri bir anlam ifade etmiyor, öte yandan, userbir e-postaya ve şifreye sahip olmak zorunda.
Taxonomy terms göze çarpan bir fonksiyonelliğe sahip oldukları için göze çarpan bir hiyerarşide, hatta dairesel bir düzene bile.
Kullanım durumunuz mevcut bir işletmeye yeterince benziyorsa, o varlığı kullanmaya devam edin. Varlığınız mevcut olanlardan önemli ölçüde farklı kurallarla yönetiliyorsa, yeni bir tane oluşturun.
Varlıklara Giriş de var , ancak ne yazık ki sorunuzu gerçekten cevaplamıyor.
Her şeyin bağlamla ilgili olduğunu düşünüyorum, bir düğüm çoğunlukla içerikler için kullanılır, böylece bloglar, makaleler, sss'ler vb.
Bir düğümü destek bileti gibi bir şey için kullanabilseniz de, en iyi şablon ve varsayılanlar olmayabilir ... Umarım yardımcı olur.
Varlıklar, düğümlerden daha az ek yük ile oluşturulabilir, çünkü varlıkların sahip olduğu tüm ağır hizmet işlevlerine sahip olmaları gerekmez.
Aynı zamanda, depolama işleminin daha basit olabileceği anlamına gelir - eğer isterseniz bütün bilgileri JOINS olmadan basit bir sorguda toplamak için oluşturabilirsiniz. Bütün alanlar güzel, sadece düzenli bir tabloda.
Varlıklar üzerinde sorgulamalar yapmanız gereken çok sayıda işleviniz varsa ve UPDATE sorguları ile aynı anda veritabanını birden fazla varlık güncelliyorsanız, bu büyük bir avantaj olabilir. Verilerin tek bir tabloda nispeten bağımsız olduğundan emin olabilirseniz, daha az kaygınız ve veri bozulma ihtimaliniz vardır.
Bir içerik türü, site içeriği olarak tasarlanmıştır. Yani, her içerik türü sitede yayınlanmak ve görünmek üzere tasarlanmıştır. Örneğin, ilk sayfada görünmesi için bir kutu (kutudan çıkar) tasarlanmıştır.
Şimdi, bir iş veya apartman başvuru formu gibi bir şey oluşturmak istediğinizi varsayalım. Açıkçası, birinin istihdam başvurusunu web sitenizde yayınlamak istemezsiniz. Ayrıca, müşteri / potansiyel müşterileriyle ilgili bir liste oluşturmak istersen? Bu bilgilerin yanlışlıkla web sitenizde yayınlanması ihtimalini almak ister misiniz? Şahsen ben yapmazdım.
Dolayısıyla, varlık yukarıda açıklanan tartışmayı oluşturur. İçerik olarak tasarlanmamış bir varlık türü oluşturmanıza olanak tanır. Ancak, bu varlık türleri, yalnızca bir kaçını adlandırmak için kurallar, görüşler ve organik grup gibi varlıkları destekleyen herhangi bir modülde kullanılabilir.
Ve sonra ürünlerin varlık tipi olduğu Drupal Commerce'e girersiniz. Temel olarak varlıklar, geliştiricilerin Drupal'ı, orijinal Drupal tasarımcıları tarafından asla öngörülmeyen şekilde genişletmelerini sağlar.
Bu tartışmaya tabidir ve sonunda kararlarınızı geliştirici olarak vermeniz gerekir.
Verilerin halka açık bir şekilde kendi URL'leriyle erişilebilir olmaması gerektiğinde düğümler üzerindeki varlıkları seçiyorum. Düğümler varsayılan olarak bir URL takma adı, yayınlanmış durum, bir başlık, meta etiketler ... alırken, varlıklar sadece veritabanında kayıt olur.
"Metin ile mümkün olduğunca fazla afiş ekleyebilmek istiyorum ve daha sonra bir blog yayınında bunlardan birini seçin"
Varlık ve İçerik
Varlık vardır Varlık Paketler sahip alanlar
İçerik bir Varlık türüdür. Yani,
İçeriğin , Alanları (gövde, makale resmi) olan İçerik Paketleri (Makale, Sayfa) vardır
Eğer programcıysanız, kesinlikle kendi Varlığınızı yaratmanın yolunu seçersiniz, ancak site üreticileri için en iyi yol bu olmayabilir. Yine site oluşturucuları için Varlık oluşturmak için kullanıcı arayüzü var http://drupal.org/project/eck