Przy obecnym statusie D8, jakie jest drzewo decyzyjne dotyczące tworzenia nowego typu encji treści w porównaniu do tworzenia typu treści dla encji treści „Węzeł”?

Widzieliśmy cztery lata i pierwsze wydanie Drupala 8, odkąd zaakceptowana odpowiedź została napisana na pytanie „ Kiedy należy utworzyć Encję, a nie tylko dodać nowy typ zawartości ?” I istoty są bardziej centralne dla Drupala 8 niż w Drupalu 7. ( RefB , RefC , RefD )

W tym nowym świecie Drupal 8 jakie jest drzewo decyzyjne dotyczące tworzenia nowego typu encji treści w porównaniu z nowym typem treści dla encji treści typu „Węzeł”?

Rozważając odpowiedź, weź pod uwagę następujące kwestie:

• Czy nowy typ treści dla typu jednostki treści „Węzeł” jest nadal odpowiedni w 99% sytuacjach w porównaniu do nowego typu jednostki treści?
• Czy drzewo decyzyjne zawiera teraz więcej, lepsze lub jaśniejsze powody, aby odejść od używania typu encji treści „Węzeł” i zamiast tego utworzyć nowy typ encji treści? A jeśli tak, jakie one są? Czy obejmują one:
  • Wydajność?
  • Bezpieczeństwo / uprawnienia?
  • Liczba modułów, które działają z typami treści typu Węzeł i nie działają z innymi typami elementów treści?
• Być może - w oparciu o poprzednią zaakceptowaną odpowiedź, do której odwołuje się powyżej - jedynym ogólnym powodem do utworzenia niestandardowego typu encji treści jest to, że chcesz pogrupować dane Węzła, np. Z terminami taksonomicznymi, lub w inny sposób opatrzyć komentarzem Węzła, np. Komentarzami?

Kompatybilność modułów wydaje się szczególnie interesującą kwestią dla drzewa decyzyjnego. Obecnie niewiele spośród najczęściej instalowanych modułów ma wersję 8.x, która nie jest jedynie wersją alfa, beta lub rc (kandydatem do wydania). I trudno jest określić, ile z nich będzie działać od razu po wyjęciu z pudełka z nowym niestandardowym typem encji w porównaniu z nowym typem encji Node. Wydaje się, że nie istnieje atrybut projektu umożliwiający rozróżnienie między tymi, które są „pisane dla encji” a „pisanymi dla typów treści encji węzłowych”.

Spójrz na pathauto, który jest obecnie czwartym najczęściej instalowanym modułem z tych, które mają jakąkolwiek wersję 8.x. Ludzie ciężko pracują nad wersją 8.x, która ogólnie obsługuje byty, a nie tylko typy treści typu węzeł. A co z pozostałymi modułami? I czy moduły obsługujące jednostki będą na ogół wymagać, aby niestandardowe typy jednostek treści miały „zaczepy” specyficzne dla modułu, zanim moduł będzie z nimi współpracował? (W przeciwieństwie do tego, jak moduły mogą działać od razu po wyjęciu z pudełka z nowymi typami treści?) To wydaje się być wyzwaniem, z którym pracuje zespół pathauto, i być może jest to powód, aby odejść od niestandardowego typu jednostki treści?

Warto również wspomnieć, że rdzeń Drupal 8 zawiera interfejs użytkownika do tworzenia nowych typów treści dla encji treści typu „Węzeł”, ale obecnie nie zawiera interfejsu użytkownika do tworzenia nowych typów encji treści. ( RefX , RefY , RefZ )

Drzewo decyzyjne wyboru między tworzeniem nowego typu treści typu Węzeł a nowym typem treści:

1. Jesteś programistą, czy masz łatwy dostęp do programisty?
   • Jeśli nie, oznacza to, że jesteś obecnie ograniczony do tworzenia nowych typów treści encji węzłowej. (W rdzeniu nie ma interfejsu użytkownika służącego do tworzenia nowych typów encji treści, a moduł Contrib Construction Kit (ECK) ma obecnie tylko wersję alfa).
   • Jeśli tak, kontynuuj ...
2. Czy wiesz dokładnie, które moduły contrib chcesz wykorzystać dla swoich danych?
   • Jeśli nie, to bezpieczny zakład prawdopodobnie polega na utworzeniu typu treści encji węzłowej.
   • Jeśli tak, to czy te moduły już obsługują niestandardowe typy jednostek, które rozważasz, czy też chcesz pomóc w ich ulepszeniu, aby mogły one odtworzyć pożądaną funkcjonalność w module?
     • Jeśli nie, to najlepsze może być utworzenie typu treści typu Węzeł.
     • Jeśli tak, kontynuuj ...
3. Czy rzeczywiste dane treści, które są włączane przez moduł, pomogą jedynie zgrupować lub opatrzyć adnotacjami inne dane treści? (Tak, że rzadko będzie oglądany samodzielnie).
   • Jeśli tak, zastanów się, czy twój moduł jest podobny do istniejących typów jednostek dla warunków taksonomicznych i komentarzy. Jeśli tak, to nowy typ podmiotu może być bezpiecznym zakładem.
   • Jeśli nie, kontynuuj ...
4. Czy potrafisz jasno wskazać, dlaczego nowy typ treści typu Węzeł nie będzie dla Ciebie działał?
   • Jeśli nie, to bezpieczny zakład prawdopodobnie polega na utworzeniu nowego typu treści typu Węzeł.
   • Jeśli tak, kontynuuj ...
5. Na koniec, czy jesteś pewien, że nie możesz po prostu rozszerzyć typu encji węzłowej i chcesz odtworzyć wszystkie jego przydatne funkcje, takie jak operacje CRUD?
   • Jeśli tak, śmiało i utwórz nowy typ encji niestandardowej.
   • Jeśli nie lub nie jesteś pewien, prawdopodobnie chcesz zaangażować ekspertów, którzy pomogą Ci podjąć decyzję.

Uwagi:

1. To drzewo decyzji nie uwzględnia wydajności ani bezpieczeństwa. Nie jestem pewien, czy lub kiedy nowy niestandardowy typ jednostki treści będzie działał lepiej i będzie mniej lub bardziej bezpieczny niż typ jednostki Node.
2. Nawet jeśli to drzewo jest dobrą odpowiedzią, prawdopodobnie nie pozostanie nim z czasem z powodu aktualizacji wydanych w jądrze Drupala i modułach contrib. StackExchange wydaje się nie uwzględniać tego, w jaki sposób „najlepsza” odpowiedź może nie być najlepszą odpowiedzią jutro).

Prostym podejściem do tego problemu jest wzięcie pod uwagę celu projektu, wielkości i wymagań biznesowych.

1. Jak domyślny typ treści elementu węzła wpływa na budowanie projektu w łatwy, zgrabny sposób bliższy architekturze i przepływom danych uzyskanym z analitycznego myślenia dokumentów projektowych.

Ważna uwaga tutaj decyzja o utworzeniu nowego typu encji jest zwykle podejmowana przez programistów lub potencjalnych klientów technicznych, a nie twórców witryn lub właścicieli projektów, którzy zarządzają aplikacją i koncentrują się wyłącznie na działalności biznesowej.

2. Drupal 8 zależy od niektórych pakietów symfony2 i jest bardziej zbliżony do frameworków, rozwoju, który tradycyjny cms mówi o Drupalu z tymi dużymi zmianami architektonicznymi, wyobrażam sobie, że budowanie nowego bytu jest lepsze niż robienie wielu dostosowań i złożonych konfiguracji nad typami zawartości bytu węzła w kolejności aby wykorzystać Drupal wśród innych platform, ponieważ wiele osób nie lubi sposobu, w jaki konfiguracja Drupal i ustawienia rozproszone, możesz spotkać się z niektórymi osobami pochodzącymi z WordPress i używanymi do konfigurowania wszystkich rzeczy z jednego formularza, co denerwuje ich podczas pracy z administracyjnym pulpitem administracyjnym Drupal.

3. Drupal 9 planuje całkowite usunięcie systemu przechwytującego i zastąpienie go dyspozytorem zdarzeń, co prowadzi do dużej potrzeby interfejsu administracyjnego do utworzenia nowej jednostki, ponieważ zmiana istniejącej funkcjonalności z kodu będzie znacznie trudniejsza dla osób, które nie są programistami i będzie bardzo niezbędna dodaj tę funkcję.

Na koniec widzę, że nowe podmioty dostosowane do potrzeb projektu zapewniają wyższą wydajność lepszą niż złożone typy treści z dużą liczbą pól, ponieważ teraz każde pole dodaje 2 tabele do bazy danych i musi załadować swoją konfigurację na każde żądanie, szczególnie z wymagana ciężka logika biznesowa.

Prosty i prosty: to nie wszystko. Lista treści może trwać dość długo i może być myląca, jeśli używasz tylko typów zawartości. ( ContentEntityBase może być również zaimplementowany przez niestandardową jednostkę)

Jeśli masz autora i opublikowałeś stan , powinieneś wybrać typ zawartości.

W przeciwnym razie (zakładając, że jesteś programistą) preferowane powinny być jednostki niestandardowe. Wiele można łatwo zaimplementować za pomocą wszystkich interfejsów (takich jak wersje, pola, ograniczenia dostępu itp.)

Moim zdaniem jest to po prostu bardziej przejrzysta i uporządkowana architektura (a także bardziej wydajna).

Myśląc o możliwości ponownego użycia w kilku projektach, aby wydmuchać niestandardowe byty. Są też sprytni pomocnicy, tacy jak generator kodu drupal . Aby utrzymać niestandardowe kodowanie (lub złożoność) na niskim poziomie, powinieneś rozważyć użycie typów zawartości, jeśli chcesz:

• Aby przetłumaczyć „byt” (przynajmniej w D7), istniałby również interfejs.
• (otwarte na sugestie) ..

To trudne pytanie, które, szczerze mówiąc, myślę, że zrozumiałe dopiero po jego wdrożeniu. Ale jak wspomniano w Remy, nie wszystko jest surowe, treść skierowana do użytkownika .

W Drupal 7 istniała możliwość tworzenia niestandardowych bytów, ale może być zniechęcającym zadaniem, jeśli będziesz miał problemy z OOP. To było w połowie zaimplementowane (lub w połowie zrobione, jak chcesz to powiedzieć), co doprowadziło do sposobów tworzenia podmiotów, które nie były dokładnie jednolite i uzgodnione podejścia, z mieszanym proceduralnym i mieszanym OOP.

W Drupal 8 pomysł jest znacznie bardziej zrealizowany i o wiele łatwiej jest rozpocząć pracę z niestandardową jednostką. Sam węzeł oparty jest na ContentEntityBase, podobnie jak bloki, użytkownicy, pliki i taksonomia.

Węzły są specjalnie przeznaczone do publikowanych, widocznych (lub autoryzowanych) danych o treści, które zwykle działają jako treść (to znaczy w menu lub w mapie witryny, mapie witryny xml lub kanałach RSS itp.). Drupal został zaprojektowany w taki sposób, abyś mógł podłączyć się do dowolnego etapu procesu pracy węzła i zmienić go, co może mieć niezamierzone konsekwencje, jeśli masz niewłaściwą kombinację modułów. Jest to prawdopodobnie kontrowersyjna opinia, ale pomaga się oderwać od idei „wszystko jest węzłem”, aby bardziej objąć koncepcję Entity.

Idealne treści, które tworzą świetne typy treści:

• Artykuł
• Strona
• Oferta pracy
• Zdarzenie
• Wstęp
• Strona główna

Ich wspólnym wątkiem jest to, że dzielą koncepcję pewnego rodzaju treści. Zwykle jest w dowolnej liczbie stanów przepływu pracy (opublikowany, promowany, lepki, zarchiwizowany, polecany itp. - jeśli korzystasz z niestandardowych opcji publikowania), a duża liczba modułów, z którymi współpracujesz, oddziałuje z nim bezpośrednio, na przykład Pathauto.

Załóżmy jednak, że chcesz przechowywać dane w Drupal, które są wewnętrzne, prywatne, napędzają inne dane lub dane, które nie powinny umożliwiać integracji poza jego zakresem, chyba że na to zezwalasz. Jakie to mogą być dane? Oto kilka możliwych typów:

• Produkt (Drupal Commerce)
• Element zamówienia (Drupal Commerce)
• Serwer wyszukiwania (ApacheSolr / SearchAPI)
• Kontakt (jak ołów CRM)
• Bilet (jak bilet pomocy technicznej)

Co sprawia, że ​​są tak różne? Dlaczego miałbyś chcieć encji do kontaktu, zamiast używać modelu użytkownika? Możesz podać kilka argumentów, ale mój przykład byłby taki, że jeśli powiesz, zbierając adresy e-mail i nazwiska oraz niektóre inne metadane z formularza kontaktowego, przechowuj te dane jako jednostkę niestandardową. Zapobiegasz zanieczyszczeniu listy użytkowników elementami niebędącymi kontami, zmniejszasz potencjalne problemy z bezpieczeństwem (co jeśli skrypt lub ktoś przypadkowo zaktualizował te konta, aby były administratorami lub wysłał masową pocztę?), Sprawujesz wewnętrzne zarządzanie faktycznym użytkownikiem konta łatwiej i segmentujesz to, co przechwytujesz, na to, co to jest, specjalistyczny bit danych.

Odtąd jest w dużej mierze oddzielony od bardziej automatycznych części systemu Drupal / Node i możesz dostosować działania i doświadczenie. Określasz trasy, dostęp i przepływ pracy CRUD.

W tym sposobie myślenia łatwiej jest zrozumieć, dlaczego podejście do tego celu byłoby tak wykonane. Weźmy przykład zgłoszenia do pomocy technicznej - są to przychodzące żądania, ale nie publikowane dane, i prawdopodobnie ma bardzo specyficzny przepływ pracy, który jest łatwiejszy do skonfigurowania niż oderwanie go od części systemu węzłów, których nie chcesz, aby był przestrzegany do.

Innym przykładem mogą być zewnętrzne, importowane dane. W większości przypadków dane te zwykle nie są wzbogacane lokalnymi danymi Drupal (nawet jeśli jest to jednostka, możesz to zrobić). To może być cokolwiek. Może to faktury, może są to książki, może ciągnie marki piwa.

Takie dane są zwykle specyficzne i wymagają kontroli poza tym, do czego przeznaczony jest węzeł. Nie oznacza to, że nie można go rozszerzyć za pomocą pola referencyjnego w węźle, aby wskazać niestandardową jednostkę (tak działał Drupal Commerce, na pewnym poziomie) w celu wzbogacenia danych. Jednocześnie izolujesz i zapewniasz kontrolę nad swoimi danymi i interfejsem użytkownika od błędnego kodu contrib wykraczającego poza jego projekt i zakłócającego twój model. Jest to prawdopodobnie mniejszy problem w D8 niż w D7, choć pewne haki pozostają.

Obecnie istnieje odpowiednia architektura zachęcająca do separacji. Nie wszystko jest węzłem.