2012-08-22 7 views
6

Czy ktoś nie ma doświadczenia w ustawianiu pola __Renderings w Sitecore, aby się nim nie podzielić? Budujemy rozwiązanie z wieloma witrynami i wieloma językami, a układy (podrzędne) powinny być różne w różnych językach. Na przykład strona w języku angielskim może mieć sublayout, którego nie ma szwedzka wersja tego samego produktu, a wszystkie składniki prezentacji nie zawsze mają to samo źródło danych dla różnych języków.Ustawienie pola __Renderings nie jest udostępniane w konsekwencjach Sitecore?

Nieco prostym rozwiązaniem byłoby po prostu wyczyszczenie pola "udostępnione" na __Renderings w polu /sitecore/templates/System/Templates/Sections/Layout template, ale czy ma to jakieś inne konsekwencje? Czy istnieje lepszy sposób na obsłużenie tego wymogu?

+1

Jedną z głównych wad jest to, że modyfikujesz szablon systemu sitodrukowego, który nie jest obsługiwany. To utrudni przyszłe aktualizacje. –

+0

Oprócz przykładu języka, istnieje również możliwość użycia do różnych prezentacji między wersjami produktów. Na przykład zmiana źródła danych w renderowaniu między wersją 1 i 2 lub po prostu zmiana kolejności sortowania renderowania. Nie jest to możliwe, gdy jest zaznaczone "udostępnione". –

Odpowiedz

2

Modyfikowanie domyślnego zachowania Sitecore w ten sposób zwykle nie jest dobrym pomysłem. Nie jest przezroczysty dla osób, które mogą pracować z systemem w przyszłości i może prowadzić do nieoczekiwanych rezultatów.

Imo, lepiej jest dokonać przełącznika wewnątrz (pod) układów, aby ładować różne pliki na podstawie bieżącego języka.

Co do konsekwencji. Będzie działać tak, jak oczekujesz, gdy pole _Rendersings stanie się niewspółdzielone. Będziesz mógł ustawić różne szczegóły prezentacji dla każdej wersji językowej. Konsekwencją jest to, że musisz teraz ustawić ją dla każdej wersji językowej ... aby zarządzanie nią było łatwiejsze.

+0

Wolałbym to zarządzać z Sitecore, a nie z kodu. Co chcę osiągnąć, to mieć pojedynczy element, który ma różne sublayouts w zależności od języka lub sortować sublayouts w różny sposób w zależności od języka. Każde sublayout może również mieć inne źródło danych w zależności od języka. Angielski może nie mieć tych samych sublayouts co szwedzki. Ponadto, należy to edytować za pomocą edytora stron. – andreasordell

1

Zamiast tego korzystałbym z urządzeń Sitecore. Dla każdego języka możesz zdefiniować Stronę, a każda strona może mieć własne Urządzenie. To zadziała w trybie natychmiastowym, jeśli masz jedną nazwę domeny dla każdego języka (www.site.com, www.site.de, www.site.fr itd.)

Jeśli masz jedną witryna (jedna nazwa hosta) dla wszystkich języków, możesz przełączać urządzenia za pomocą procesora potoku httpRequestBegin.

W tym artykule, http://briancaos.wordpress.com/2012/04/12/identifying-mobile-devices-in-sitecore/, opisano sposób identyfikowania urządzeń mobilnych. Nie jest trudno przepisać logikę, aby zmienić urządzenia w zależności od języka.

Po zdefiniowaniu różnych urządzeń dla każdego języka wystarczy po prostu umieścić symbole na urządzeniu odpowiadającym językowi. I wciąż masz możliwość awaryjnego urządzenia dla wszystkich stron, na których wszystkie renderowania są takie same.

Modyfikacja domyślnego zachowania Sitecore może na razie zadziałać, ale używanie i rozszerzanie platformy Sitecore jest lepszym rozwiązaniem.

+0

To jest interesujące! Chociaż nie jestem pewien, jak łatwo będzie to redaktorom internetowym, korzystając z edytora stron Sitecore. Zajrzę do tego więcej! – andreasordell

+0

W przypadku witryny z 5 językami, po dodaniu nowego wspólnego składnika należy dodać ją ręcznie do wszystkich 5 języków. To wymagałoby dużo dodatkowej pracy i testów. Przypuszczam, że zależy to od tego, jaki procent struktury treści jest wspólny. Jeśli tak czy inaczej, to może być OK. – GeekyMonkey

5

Moja własna preferencja przy wymianie elementów wizualnych opartych na języku, kraju pochodzenia itp. Polega na użyciu edycji personalizacji Sitecore w celu wymiany źródeł danych i zmiany prezentacji w ten sposób. Nie wymaga zmiany domyślnego zachowania Sitecore i umożliwia korzystanie z wbudowanej funkcjonalności Sitecore.

Jeśli różne "sublayouts" są w rzeczywistości tylko źródłami danych pobieranymi przez różne reguły personalizacji, możesz to wszystko skonfigurować za pomocą OMS/DMS i polegać na silniku Sitecore, aby zaprezentować komponenty, których potrzebujesz, biorąc pod uwagę obecny stan. Jeśli chodzi o wydajność, prawdopodobnie najlepsze jest korzystanie z najnowszej wersji DMS (uważam, że aktualizacja 6.5 jest teraz zalecaną wersją).

+0

Korzystanie z DMS zdecydowanie może być świetną opcją. Pozwala również użytkownikowi edytować za pomocą edytora stron. Może być nieco skomplikowany dla zwykłych użytkowników, aby zrozumieć, jak używać personalizacji. Zmiana pliku danych jest kluczowym aspektem, ponieważ nie wszystkie elementy mają wszystkie języki itp. Czy parametr personalizacji jest dostępny dla personalizacji? – andreasordell

+0

Jeśli otworzysz edytor zestawu reguł podczas personalizowania komponentu, zobaczysz dużą listę udostępnionych warunków/reguł. Jedna z sekcji, jeśli dla "Przedmioty", z regułą "gdzie język przedmiotu porównuje się do wartości". Istnieją również zasady dotyczące witryn, a także osób. –

+0

Powiedziałbym, że jest to "lepszy sposób na obsłużenie tego wymogu", a zatem odpowiedź na twoje pytanie. Z mojego doświadczenia wynika, że ​​mieszanie się z Sitecore w sposób, który sugerujesz, doprowadzi cię do kłopotów. Może nie teraz - przetestowałem to sam, i nie ma wielu naprawdę poważnych efektów ubocznych - ale później. –

1

Rzeczywiście to zrobiliśmy, a większość z nich ma niewiele skutków ubocznych. W rzeczywistości jest to jedyny sposób uzyskania przepływu pracy w przypadku zmian __Renderings. Łączymy ją z Partial Language Fallback, aby języki mogły dziedziczyć wartość z języka angielskiego.Bądź jednak ostrożny, tak jakby element został sklonowany, zawsze pobiera domyślną wartość z klonu, zamiast standardowych wartości/kreacji zastępczej.

Powiązane problemy