Лучшая практика для отношений «многие ко многим» между элементами дерева контента?

В моем дереве контента есть дерево элементов контента, которые представляют города. Для каждого из них я хочу иметь логические связи с набором... скажем... национальных парков, которые находятся в пределах 2 часов езды. Таким образом, в городе будет несколько парков... и каждый набор будет отличаться... но, конечно, парк также будет связан с более чем одним городом.

Какая настройка элемента и поля подходит для такой ситуации? Я буду создавать собственный рендерер для этих элементов, поэтому меня больше всего волнует, как это должно выглядеть в Sitecore, чтобы максимально упростить использование и повысить производительность.

Я использую Sitecore 6.2.

(перекрестная публикация из SDN, пожалуйста, простите меня... но я хочу привлечь больше сообщества Sitecore здесь, в StackOverflow)


sitecore sitecore6
person Bryan    schedule 17.02.2010    source источник
comment
Если это M:N, это не дерево. просто говорю... ;-)   -  person Sky Sanders    schedule 18.02.2010
comment
Я так понимаю, вы не знакомы с Sitecore... Все является частью дерева контента.   -  person Bryan    schedule 18.02.2010

Ответы (3)


arrow_upward
2
arrow_downward

Для такого рода отношений вам понадобится следующая структура:

Домой

   Cities

       NY
       London
       Paris

   Parks

       Park1
       Park2
       Park3

Шаблон «Город» должен иметь поле типа Мультисписок с названием «Парки». Суть этого поля должна смотреть в корень Парков (Главная > Парки). Точно так же шаблон «Парк» имеет поле «Мультилист» под названием «Города». Источник этого поля должен смотреть на корень Cities (Home > Cities).

Таким образом, вы легко сможете выполнить любой запрос.

Надеюсь это поможет.

person Yan Sklyarenko    schedule 18.02.2010
comment
Единственная проблема с этой моделью заключается в том, что вы должны поддерживать ассоциации в двух местах. Например, если вы добавите Park1 в поле мультисписка (или, что еще лучше, в древовидный список) в NY, вам также необходимо добавить NY в поле мультисписка в Park1. Однако вы можете настроить обработчик сохранения и удаления, как предложил Габриэль, чтобы сделать этот процесс немного более свободным от рук. - person Adam Weber; 18.02.2010
comment
Спасибо Ян, это лучший ответ на данный момент. - person Bryan; 18.02.2010

arrow_upward
2
arrow_downward

Если соединение должно быть двусторонним, вы можете справиться с этим, добавив некоторый код в событие сохранения.

Предположим, у нас есть шаблон «Город» с полем «Связанные парки» и шаблон «Парк» с полем «Связанные города».

Скажем, мы сохраняем элемент «Город» с двумя парками в поле «Связанные парки». В событии сохранения мы могли бы получить два парка и вставить текущий сохраняемый город в поле «Связанные города» в этих парках.

Я не обязательно говорю, что это лучший способ сделать это, просто еще один вариант.

person Gabriel Boys    schedule 18.02.2010
comment
Как подключиться к событию сохранения для одного элемента или типа шаблона? Раньше я не мог понять, как это сделать, поэтому добавить такой обработчик было проблематично. - person Bryan; 18.02.2010

arrow_upward
0
arrow_downward

Собираетесь ли вы делать какие-либо поиски из парка в город? Например, нужно ли вам сказать «найти все города, связанные с данным парком»? Или это будет просто «найти все парки, связанные с данным городом»? Если вам нужно выполнять поиск в обоих направлениях, все становится немного сложнее, и я, вероятно, порекомендую использовать поисковый индекс. Однако, если ваш поиск осуществляется только в одном направлении, вы можете просто использовать поле древовидного списка для сопоставления одного элемента со многими другими.

Из вашего описания я не совсем уверен, действительно ли вам нужно использовать отношения «многие ко многим» или вам нужен путь «один ко многим»?

person Adam Weber    schedule 18.02.2010
comment
Если ему нужно переместить парк в город, он может просто сделать рендеринг с другой точки зрения? Маловероятно, что любая другая структура подойдет для веб-интерфейса. - person Sky Sanders; 18.02.2010
comment
Да, в конечном итоге мы будем выполнять поиск в обоих направлениях. Я не знаком с поисковым индексом. Я думаю, вы могли бы смотреть на это как на множественное "один ко многим"... но разве это не одно и то же? - person Bryan; 18.02.2010