Jakie są zalety tworzenia nowych typów encji w porównaniu z budowaniem nowego typu treści?
Wydaje się nieco przesadne wykonywanie całego niestandardowego kodowania, które jest wymagane do utworzenia nowego elementu, gdy wszystkie funkcje CRUD i widoki są już wbudowane w typy zawartości.
Odpowiedzi:
Nie chodzi tylko o korzyści, ale o to, co jest odpowiednie w konkretnej sytuacji, jak powiedziałeś. Możesz reprezentować prawie wszystko z węzłem i dla 99% sytuacji (jak przynajmniej znalazłem) nie będziesz musiał implementować niestandardowych typów encji.
Zawsze myślę o taxonomy_termtypie jednostki jako dobrym przykładzie, dlaczego nie wszystko powinno być typem węzła / treści:
Pojęcie taksonomii służy zasadniczo do grupowania różnych jednostek i jako takie nie wymaga takiej samej funkcjonalności jak węzeł. Chociaż teoretycznie można użyć typu zawartości do wykonania tej funkcji (z być może polem odniesienia do węzła), termin taksonomiczny nie musi robić tego samego co węzeł, więc nie ma sensu tego robić. To samo można powiedzieć o typach useri taxonomy_vocabularyjednostkach.
Tak więc termin taksonomiczny jest tworzony jako oddzielna jednostka i jest zaprogramowany do robienia tylko tego, czego potrzebuje, przy jednoczesnym korzystaniu z możliwości dołączania pól itp.
Myślę, że prosta odpowiedź jest taka, że gdy typ węzła / treści nie robi tego, czego potrzebujesz, lub jest to po prostu ogromna nadwyżka / nadwyżka dla bardzo niewielkiej korzyści, powinieneś napisać niestandardową jednostkę.
Jest to oparte wyłącznie na moim osobistym doświadczeniu; Chciałbym usłyszeć, co ktoś o tym powiedział bezpośrednio związany z rozwojem rdzenia Drupala.
Bardzo prostą zasadą, której używam, jest to, czy Twoje treści muszą być publicznie wyświetlane samodzielnie. Jeśli tak, to przejdź do węzła, jeśli nie, wybierz jednostkę. Entityforms pozwala teraz stworzyć interfejs do wypełniania swoich bytów.
Na przykład na stronie internetowej wykonanej za pomocą D6 tworzymy typ treści reklamowej (z polem obrazu, datą rozpoczęcia / zakończenia wyświetlania ...), ale wtedy musisz ustawić, aby nie była ona domyślnie publikowana i dać redaktorom prawo do edycji / view the node i mam nadzieję, że żadne widoki / search nie wyświetlą ich na zewnątrz. Jest to dość kłopotliwe i łatwiej byłoby poradzić sobie z bytami.
Jednostka reprezentuje konkretny przypadek użycia .
Uważam, że uznanie tej prostej definicji należy do Fago , ale jestem leniwy, by znaleźć referencję.
Gdybyśmy chcieli, moglibyśmy użyć Content(aka Nodes) dla wszystkich przypadków użycia, ale często nie ma to sensu.
Content ma autora i ustawienia zarówno komentarzy, jak i lokalizacji menu.
Users, reprezentują przypadek użycia wystarczająco odmienny od tego, Contentponieważ w userżadnym z powyższych nie ma żadnego sensu, natomiast z drugiej strony usermusi mieć adres e-mail i hasło.
Taxonomy terms wyróżniają się, ponieważ mają wbudowaną funkcjonalność, która może być ułożona w hierarchię, nawet okrągłą.
Jeśli twój przypadek użycia jest wystarczająco podobny do istniejącej jednostki, skorzystaj z tej jednostki. Jeśli jednak twoja jednostka rządzi się znacząco innymi regułami niż jakiekolwiek istniejące, utwórz nową.
Istnieje również wprowadzenie do bytów , ale niestety tak naprawdę nie odpowiada na twoje pytanie.
Myślę, że wszystko zależy od kontekstu, węzeł jest w dużej mierze wykorzystywany do treści, więc będą to blogi, artykuły, najczęściej zadawane pytania itp. Podczas gdy użytkownik dla profili takich jak personel, klienci itp. Przykład, kiedy możesz utworzyć nową enitity:
Chociaż możesz użyć węzła do czegoś takiego jak bilet pomocy technicznej, może nie być najlepszym szablonem i domyślnie ... Mam nadzieję, że to pomaga.
Jednostki można tworzyć z mniejszym narzutem niż węzły, ponieważ nie muszą one mieć wszystkich zaawansowanych funkcji, które mają jednostki.
Oznacza to również, że przechowywanie może być prostsze - możesz je zbudować, aby pobrać wszystkie informacje w prostym zapytaniu bez ŁĄCZENIA, jeśli chcesz. Wszystkie pola ładnie w jednym uporządkowanym stole.
Może to być ogromną korzyścią, jeśli masz wiele funkcji, które muszą wykonywać zapytania dotyczące encji, i aktualizujesz wiele encji jednocześnie za pomocą zapytań UPDATE do bazy danych. Jeśli możesz upewnić się, że dane są względnie samowystarczalne w jednej tabeli, masz mniej obaw i możliwości uszkodzenia danych.
Typ zawartości ma być treścią witryny. Oznacza to, że każdy typ zawartości jest przeznaczony do publikowania i pojawiania się na stronie. Na przykład artykuł (po wyjęciu z pudełka) jest przeznaczony do wyświetlania na pierwszej stronie.
Powiedzmy, że chcesz utworzyć formularz wniosku o pracę lub mieszkanie. Oczywiście nie chciałbyś publikować czyichś ofert pracy na swojej stronie internetowej. A co jeśli chcesz zbudować listę kontaktów z klientami / potencjalnymi klientami? Czy chcesz zaryzykować opublikowanie tych informacji przez pomyłkę w Twojej witrynie? Osobiście nie zrobiłbym tego.
Stąd moduł formy encji omówiony powyżej. Umożliwia tworzenie typu encji, która nie została zaprojektowana jako treść. Jednak te typy jednostek są dostępne dla każdego modułu obsługującego elementy, takie jak reguły, widoki i grupa organiczna, aby wymienić tylko kilka.
A potem wchodzisz do Drupal Commerce, gdzie produkty są typami jednostek. Zasadniczo podmioty umożliwiają programistom rozbudowę Drupala w sposób nigdy nie przewidziany przez oryginalnych projektantów Drupala.
Jest to przedmiotem dyskusji i ostatecznie musisz podjąć decyzję jako programista.
Wybieram jednostki ponad węzłami, ilekroć dane nie powinny być publicznie dostępne z ich własnym adresem URL. Węzły domyślnie otrzymują alias adresu URL, status opublikowania, tytuł, metatagi, ... a jednostki po prostu pobierają rekord w bazie danych.
„Chcę mieć możliwość dodania jak największej liczby banerów z tekstem, a następnie w blogu wybrać jedną z nich”
Podmiot a treść
Jednostka ma pakiety jednostek, które mają pola
Treść jest rodzajem podmiotu. Więc,
Treść zawiera pakiety treści (artykuł, strona), które mają pola ( treść , obraz artykułu)
Jeśli jesteś programistą, z pewnością wybierasz ścieżkę tworzenia własnego Entity, ale dla twórców stron może to nie być najlepsza ścieżka. Ponownie dla twórców stron dostępny jest interfejs użytkownika do tworzenia Entity http://drupal.org/project/eck