Sitecore Drzewo Content Architecture

Question

Powiedzmy istnieje prezentacyjny elementem projektu, który renderuje listę nieuporządkowaną Mamy kilka opcji dostarczania danych do dowolnej ListRenderer na stronie (tzw ListRenderer, być może.):

1. Mieć pole TreeList (lub TreeListEx) na elemencie treści i mieć od niego odczyt ListRenderer.
2. Podaj DataSource (lub inny parametr) do ListRenderer poprzez szczegóły prezentacji.

Zazwyczaj unikam # 1 w moich projektach, ponieważ wiąże Sublayouts z szablonami, co staje się dość niechlujne. Jeśli pójdziesz tą ścieżką, w końcu będziesz miał pola do obsługi każdego potencjalnego sublayout w twoim projekcie.

Więc moje rozwiązania zmierzają w kierunku opcji nr 2, która pozbywa się tego problemu. Ma jednak własną torbę pytań. Gdzie mogę umieścić te różne "Listy" dla danego ListRenderer do użycia? Aby zmaksymalizować ponowne wykorzystanie i udostępnianie, zazwyczaj utworzę katalog komponentów w pobliżu katalogu głównego witryny, który zawiera wszystkie te typy rzeczy, jeśli przewiduję udostępnienie list. Wydaje się, że jest to mniej czytelne i trudniejsze w użyciu dla autora treści, który nagle nie ma pojęcia, gdzie znajduje się źródło ich ListRenderer, chyba że wie, jak otworzyć szczegóły prezentacji (co jest nieco zaawansowane dla mojego przeciętnego użytkownika).

Jeśli mam wrażenie, że Listy nie będą udostępniane i są bardzo specyficzne dla strony, umieszczę je bezpośrednio pod danym elementem. Ma to jednak skłonność do pomieszania drzewa treści, a każde dynamicznie generowane podwiązanie nawigacyjne musi sprawdzić, czy element jest rzeczywistą stroną, zanim wygeneruje link do niego. Im bardziej pracuję w Sitecore, tym rzadziej używam tego podejścia, ale autorowi treści wydaje się łatwiej. Dostęp do informacji jest znacznie łatwiejszy, gdy używasz tego podejścia.

Czy istnieje jakiś akceptowany przez przemysł sposób podejścia do tego problemu? Zdarza się to w projektach przez cały czas iw mojej głowie walczę o zrównoważenie problemów technicznych i dotyczących treści w takich sytuacjach.

Answer 1

Jak zauważył Mark, nie ma prawdziwego standardu branżowego.

Czuję, że to jest coś, co wymaga poprawy. Szczególnie w przypadku korzystania z opcji DataSource rzeczy stają się mniej przejrzyste dla redaktorów, a wraz z powiększaniem się witryny rośnie złożoność.

Wszystko, co mogę powiedzieć, to to, jak bym to zrobił, co najprawdopodobniej bardzo przypomina sposób, w jaki to robisz.

1) W przypadku stron poglądowych, takich jak aktualności, wydarzenia i pozycje FAQ, umieściłem pozycje pod elementem przeglądu i skorzystałem z modułu źródła współdzielonego NewsMover, aby automatycznie utworzyć hierarchię.

2) Utworzę globalną witrynę zawierającą elementy, które są udostępniane w witrynach lub na stronach. Elementy DataSource dla komponentów zostaną tutaj umieszczone.

3) W przypadku składników, które są obecne na standardowych wartościach dodam pole listy do szablonu (na przykład podczas wyświetlania związanych elementów na stronie Content)

Najczęściej jest to logiczny wybór i czasami to tylko kwestia gustu.

Chciałbym dodać, że napisałem blog post o tym, jak automatycznie tworzyć elementy źródeł danych dla komponentów, które są ustawione na wartości standardowe. To może ci pomóc, jeśli używasz ich.

Edit: „Ja zwykle unikać nr 1 w moich projektów, ponieważ wiąże Sublayouts do szablonów, które robi się dość niechlujny Jeśli pójdziesz tą drogą, w końcu będziesz miał pola do wspierania każdego potencjalnego sublayout w swoje. projekt."

Dziś mam blogged o metodzie ukrywania pól i sekcji w edytorze treści, jeśli nie ma ustawionego sublayout na elemencie, który wymaga tych pól, co pomaga zapobiec bałaganowi posiadania wielu nieużywanych pól na twoim przedmiotów.

Answer 2

Świetne pytanie. Użyłem wszystkich wymienionych technik, w zależności od odbiorców i specyfiki projektu. Problem polega na tym, że tak jak w przypadku wszystkich rzeczy Sitecore, wszystkie one są ważnymi sposobami osiągnięcia tego samego celu, a będziesz miał trudności ze znalezieniem jednej odpowiedzi, która zadziała w każdej sytuacji.

Prawie zawsze używam również nr 2, ale może być konieczne przekwalifikowanie autora treści i dopilnuj, aby dodać ograniczenia do tego, co autor treści może wybrać jako cel. Mam (w ramach tego samego projektu) strukturę elementów w pobliżu katalogu głównego (w folderze współdzielonych treści) i pod danym elementem, w zależności od tego, co czułem, aby zapewnić najlepszy kontekst.

Ponadto, jeśli inne podrzędne elementy istniałyby pod elementem, a także elementami listy, to umieszczałem elementy listy w oddzielnym folderze (ze wspólną ikoną "elementów listy") i ponownie zamawiam na Bądź pierwszy element do oddzielania i jasności.

Jeśli chcesz użyć jakiejkolwiek personalizacji i DMS to trzeba będzie możliwość przełączania się źródło danych tak więc nie należy lokalizacje twarde kod.

ty może również (jeśli jeszcze nie) chcesz rozważyć użycie:

Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- przydatna, gdy trzeba zrestrukturyzować swoje treści w późniejszym terminie

Queryable Datasource Locations
- Przydatne w sytuacjach, w wielu lokalizacjach, gdy trzeba dokonać klonów lub ustawić jako wartość domyślną źródła danych w standardowych wartości, gdy listy są bezpośrednio pod elementem, ale daje Ci możliwość zmiany.

Preferuję osobiście korzystać z możliwych do przetestowania źródeł danych, uważam, że składnia xpath jest bardziej logiczna.