Zastanawiam się, jak zdecydować się na użycie podstawowego modułu taksonomii lub modułu odniesienia jednostki ?

Nie korzystałem wcześniej z modułu Entity Reference, ale korzystałem z modułu taksonomii (i niektórych powiązanych modułów) na 10-15 stronach internetowych.

Jakie są zalety lub wady korzystania z modułów opartych na referencjach zamiast modułu taksonomii?

Ostatnio zacząłem budować witrynę archiwum czasopism.

Istnieje wiele czasopism. Te magazyny mają problemy. Każdy numer zawiera artykuły.

Najmniejszą (i najgłębszą) częścią są artykuły .

Artykuł

• Numer strony (zakres):
• Tytuł:
• Autor:
• Rodzaj artykułu:
• Słowa kluczowe:
• Czasopismo:
• Kwestia:

Kwestia

• Numer wydania:
• Okładka:
• Data opublikowania):
• Czasopismo:

Czasopismo

• Opis:
• Okładka:

Tutaj są (przynajmniej) 2 metody implementacji tej strony:

1. Zostanie wywołany typ zawartości, articlea wszystkie pozostałe (numer, czasopismo, autor) będą terminami taksonomicznymi (hierarchicznymi). Byłaby hierarchia między wydaniem a czasopismem itp.

2. Będzie wiele rodzajów treści: artykuł, numer, czasopismo, autor. Podczas tworzenia artykułów; numer wydania, czasopismo i autor, itp.

Teoretycznie oba sposoby wydają się bardzo podobne.

Czy jest ktoś, kto znalazł się w podobnej sytuacji i czy mógłbyś powiedzieć, którą metodę preferujesz, dlaczego?

Istnieją również inne rozwiązania twojego problemu.

Kolekcja terenowa

Można użyć kolekcja pola i widoki kolekcja pole moduły do sklepu i organizować zawartość. Korzystając z tego podejścia Issuei Magazinebędzie typu Field Collection, Issuejest polem Articlei Magazinejest polem Issue. Mam doświadczenie we wdrażaniu takiej struktury. W moim przypadku wymaganie było takie, Libraryktóre powinno zawierać książki (z polami Tytuł, Wydawca i ...), Każda książka zawiera wiele tomów (Liczba stron, tłumacz, ...), a każdy tom zawiera także nieograniczoną liczbę innych pozycji (np. skan niektórych stron, które nie są takie same wśród książek).

Zaimplementowałem to za pomocą metody Field Collection i jest to bardzo miłe. Możesz łatwo utworzyć link do edycji poszczególnych elementów każdej kolekcji pól, a także możesz filtrować według elementów kolekcji pól. Opublikowałem odpowiedź na pozycje grupy w widokach według wartości w Field Collection, która pokazuje, jak pracować z widokami Field Collection

Załącznik do widoku jednostki

Znany również jako moduł EVA .

„Eva” to skrót od „Entity Views Attachment”; zapewnia wtyczkę wyświetlania Widoku, która umożliwia dołączenie wyjścia Widoku do zawartości dowolnej encji Drupal. Treść węzła lub komentarza, profil konta użytkownika lub strona z listą terminów taksonomii są przykładami treści encji.

Za pomocą EVA można wyświetlać tylko wartości pól dla określonego fragmentu treści, co daje niesamowitą kontrolę nad wyświetlaniem i elastyczność formatowania pól. Na przykład możesz chcieć mieć dwa pola połączone w specjalny sposób. Możesz dodać swoje pola do wyświetlacza EVA, ustawić filtr kontekstowy na NID, dodać Globalne: Pole tekstowe i używając tokenów sformatować swoje pola za pomocą HTML. Nie zapomnij wykluczyć swoich pól z wyświetlania, jeśli zamierzasz używać ich razem w polu Global: Text. Przykład: możesz mieć miasta, województwa i pola zip. Możesz połączyć je w Globalne: Pole tekstowe w Widokach, aby wyświetlić je jako „Miasto, stan ZIP”. Kiedy zarządzasz wyświetlaczem dla swojego typu zawartości, dodaj właśnie utworzoną EVA do wyświetlacza i za każdym razem, gdy wyświetlany jest typ węzła, przekaże swój identyfikator do EVA, a EVA zwróci wybrane pola, sformatowane według własnego uznania. (źródło :EVA and Entity Reference Use Case How-to )

Ten moduł jest idealny, dołącza widok jako pole do węzłów typu zawartości. Użyłem tego modułu do stworzenia Album. Album zawiera singer(z pewnymi informacjami o każdym) i songszawiera plik, tytuł, ocenę i ... Więc stworzyłem widok typu EVA i podłączyłem go do węzła. Tak więc na stronie węzła każdego piosenkarza wyświetlałem ten widok, który pobiera odpowiednie informacje z węzła. Te poglądy z podmiotu referencyjnego jest doskonały poradnik o tym, jak korzystać z tego modułu.

Warunki taksonomii Odniesienie do jednostki

Polecam przeczytanie Referencji jednostki a taksonomia i czy są jakieś korzyści / zastrzeżenia związane z używaniem Referencji jednostki w stosunku do referencji terminu? , Jak napisano, taksonomie najlepiej nadają się do organizowania podobnych pozycji w sposób hierarchiczny. Jak tagi .

Taksonomia umożliwia korzystanie z bezpłatnego tagowania (można ją wyłączyć za pomocą modułu Taksonomia treści ), co umożliwia tworzenie nowych tagów w locie. Bardzo łatwo jest zmodyfikować szkielet treści. Stosując to podejście, zwykli lub przynajmniej uwierzytelnieni użytkownicy (którzy nie mają wiedzy o programowaniu) mogą zmienić ten szkielet. Hierarchiczny moduł Select jest doskonałym przykładem takiego podejścia.

Chociaż taksonomia jest łatwa w użyciu, ale ja osobiście wolę Entity Reference, otwiera ona wiele możliwości i skalowalności oraz pozwala na tworzenie bardzo złożonych struktur. Pojęcie bytu w tym kontekście nie ogranicza się do treści. Mogą to być komentarze, użytkownicy, taksonomie i ... Jest znacznie bardziej skalowalny, więc nie będziesz się martwić dostosowywaniem typów treści lub modyfikowaniem jej w przyszłości (jak wskazano w Odwołaniu do encji vs. taksonomii ). Uważam, że podejście Entity ma większą moc niż taksonomia.

Istnieją również inne kombinacje tych podejść, o których nie trzeba wspominać.

W każdym razie zalecam pełne zrozumienie podejścia Entity i powiązanych z nim modułów. Jeśli użyjesz go w wielu projektach, pomimo jego złożoności, będziesz bardzo łatwy w użyciu. Nie tylko w zamierzonej bieżącego zapotrzebowania, ale także w przyszłości zamierza być bardzo niezawodne narzędzie dla Ciebie.

Możesz także mieć inną kombinację, na przykład artykuły i numery to węzły, a czasopisma to taksonomie.

Naprawdę nie ma na to dobrej lub złej odpowiedzi, sprowadza się to do osobistych preferencji, konkretnych wymagań projektowych itp.

Najlepiej jest używać węzłów dla treści i taksonomii do kategoryzacji tych treści, jednak czasami może być nieco mętny, czy coś jest tylko kategoryzacją, czy własną treścią.

Na przykład pola typu artykułu i słów kluczowych wydają się w oczywisty sposób taksonomiami, ale wydania i czasopisma naprawdę mogą pójść w obie strony.

Jedną z rzeczy, które mogą wpłynąć na twoją decyzję, jest nieszablonowa funkcjonalność. Na przykład istnieje wiele dodatkowych modułów dla węzłów niż dla taksonomii, ale dla taksonomii można wyjść ze stron z listami pól (jeśli chcesz). Może również istnieć funkcjonalność związana z hierarchią, która jest łatwiejsza do wyjęcia z jednego lub drugiego rozwiązania.

Definicje typów treści są tylko częścią obrazu. Zdecydowanie powinieneś w pełni zastanowić się, w jaki sposób zamierzasz prezentować treść użytkownikowi, jak chcesz, aby użytkownik poruszał się po hierarchii treści, jak ta treść odnosi się do innych treści w witrynie, jak chcesz, aby administratorzy zarządzali tą treścią treść itp. Na przykład, czy chcesz jakiś hierarchiczny system menu, czy chcesz, aby ludzie mogli odwiedzać czasopisma lub wydawać strony, czy też treść jest powiązana z tymi widocznymi tylko na stronach artykułów. Czy chcesz mieć jedno wyszukiwanie, które zawiera wszystkie 3 typy treści (może to być mniej trywialne, jeśli niektóre są węzłami, a niektóre są terminami taksonomicznymi).

Zaplanuj wszystko, a następnie sprawdź, jakie moduły są dostępne, aby to osiągnąć. Możesz znaleźć jeden sposób, który ułatwi osiągnięcie tego, co chcesz. Jeśli nie, musisz wybrać ten, który uważasz za najlepszy z jakichkolwiek powodów.

Czasami możesz pójść w jedną stronę, a następnie znaleźć coś, co utrudnia spełnienie twoich wymagań. Jeśli planujesz to jak najwięcej, zmniejszasz to ryzyko.

Innym aspektem przy stosowaniu terminów taksonomicznych do rzeczy takich jak „Magazyn” jest to, że stracisz funkcjonalność, taką jak rewizja i komentarze do tych pozycji. Przyznane wersje można dodać za pomocą modułu, takiego jak wersja Taksonomii, ale jest to moduł o bardzo niskiej bazie instalacyjnej. Osobiście zaufałbym temu rdzeniu w kwestii obsługi zmian w węzłach.

Mogę wymyślić co najmniej jedną okazję, kiedy musiałem zmienić coś z pojęcia taksonomii na węzeł po uruchomieniu projektu z powodu zmian wymagań, a to wymaga sporo restrukturyzacji i migracji.

Prawdopodobnie przekonasz się, że jeśli przejdziesz do korzystania z innych typów encji, takich jak węzły z encja_referencji, nie będziesz miał żadnych problemów ze zmianą, ponieważ wszystko działa w ten sam sposób, ale zapewni ci większą elastyczność.

Nie powiem, że to najdokładniejsza odpowiedź, ale tak o tym myślę. Wyjaśnię kilka przykładów.

Zazwyczaj używam taksonomii do klasyfikowania węzłów na podstawie abstrakcji. Na przykład wiadomości można podzielić na sportowe, polityczne itp.

Ale kiedy chcę mieć referencje takie jak czasopismo, myślę o przyszłości. Zastanów się, kiedy chcesz pomóc użytkownikowi zdecydować, który artykuł wybrać. Możliwa jest ranga magazynu (być może Impact Factor). A może chcę się skontaktować z tym magazynem. Termin nie pomógłby mi w tej sytuacji, gdyby to był węzeł lub byt.

Z drugiej strony musisz zrobić coś sam. Na przykład kliknięcie terminu systematyki prowadzi do strony wypełnionej skategoryzowanymi węzłami tego terminu. Więc teraz potrzebny jest widok i filtr kontekstowy itp.

Byłem pewien, że ktoś zapytał, dlaczego miałbym trzymać się z dala od zbiorów w terenie, ale wydaje się, że komentarz został usunięty. Tak czy inaczej moje 2 centy:

Do klasyfikacji i kategoryzacji należy stosować taksonomie. Nie dotyczy relacji treści. Łącząc 2 elementy treści za pomocą terminu systematyka, używasz 3 podmiotów, w których potrzebujesz tylko 2.

Z mojego doświadczenia wynika, że ​​chociaż taksonomie są obecnie dostępne, nie są one jednak pełnoprawnymi podmiotami i dlatego nie powinny być stosowane jako „treść”.

W tym konkretnym przypadku, jeśli Twój magazyn zawiera treść (opis, szczegóły na temat zamawiania itp.) Lub własną „stronę”, powinien to być typ zawartości, ponieważ jest treścią.

Problemy są trochę niejednoznaczne, ale istnieje prawdopodobieństwo, że masz przegląd itp., Więc prawdopodobnie mają stronę i prawdopodobnie również treść. Więc inny typ zawartości.

Artykuły są oczywiście typami treści.

Budując do tego celu administratora, możesz użyć Entity Reference, aby połączyć te fragmenty treści, ale możesz przejść jeden lepszy.

W ten sam sposób, w jaki @Drupalist zasugerował użycie Field Collection, możesz używać wbudowanych formularzy encji (myślę, że jest to część Entity Reference). Kolekcje terenowe są jednym z tych starych modułów, które były świetnym pomysłem, niezbyt dobrze wdrożonym i powodującym wiele kolizji z innymi modułami. Mimo że są teraz bytami, nadal mają problemy i lepiej byłoby używać pełnoprawnych bytów (nawet typów treści) do rzeczy takich jak autorzy itp.

Wbudowane formularze encji pozwalają tworzyć i edytować encje, do których istnieją odniesienia, z encji, z której chcesz się odwoływać ... więc twórz / edytuj autora z wnętrza artykułu lub po prostu odwołaj się do już utworzonej.

Dodaj CER, a automatycznie otrzymasz referencję od autora z powrotem do artykułu, artykuł z powrotem do wydania i problem z powrotem do Magazynu lub w jakimkolwiek kierunku. Ma to zalety w zakresie skuteczności twoich widoków, ale pozwala także wyświetlać listę artykułów na stronie autora oraz informacje o autorze na stronie artykułu, w ogóle bez widoków.

Okrąż z powrotem do taksonomii, a następnie użyjesz ich do „oznaczenia” artykułów itp. Za pomocą… „połowów”, „samochodu”, „komputerów” itp. Cokolwiek… abyś mógł znaleźć dowolny numer, czasopismo, artykuł lub autor, który ma treść / napisane o tym tagu.

Próbowałem zrobić to krótko, więc mam nadzieję, że to pomaga i ma sens. Zrobiłem to na kilkudziesięciu stronach. Globalne wydarzenia sportowe, rezerwacje podróży / wakacji, międzynarodowi nadawcy, napoje, organizacje charytatywne itp. Solidny, wydajny i chroni Cię przed nieprzewidzianymi wymaganiami.