Sitecore: как избежать нарушения зависимостей элементов, на которые ссылаются через Control-Datasource

Использование Sitecore.NET 6.3.0.

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

Поскольку эта ссылка указывается через путь, а не идентификатор, к связанному элементу, в настоящее время можно разорвать ссылку, если вы измените местоположение связанного элемента или полностью удалите его.

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

Я знаю, что можно ссылаться стандартным способом (ссылка по идентификатору), но это исключит любые ссылки, где мы должны ссылаться через относительные пути.

Есть ли способ обнаружить или даже лучше предотвратить неработающие ссылки такого рода?

РЕДАКТИРОВАТЬ: это больше похоже на назначение DataSource подмакету в деталях макета презентации, а не выполнение чего-либо в коде. (Это то, что сделал бы редактор контента).


person Dan    schedule 22.06.2011    source источник
comment
Вы имеете в виду, как назначить DataSource подмакету в деталях макета презентации, или вы имеете в виду передачу DataSource в WebControl через C#?   -  person Mark Ursino    schedule 23.06.2011
comment
Скорее прежнее. Посмотреть правки...   -  person Dan    schedule 27.06.2011


Ответы (1)


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

Читая ваш пост, я подумал... хотя и непослушный ход, но вы МОЖЕТЕ изменить тип поля "Источник данных". Конечно, возиться с системными шаблонами следует с осторожностью, но в этом случае альтернатива выглядит немного хуже.

В этом случае вам также потребуется подключиться к конвейеру getRenderingDatasource и переопределить шаг GetDatasourceLocation.

Я не делал этого сам, поэтому не могу гарантировать, что это сработает. Однако выглядит довольно прямолинейно :-)

person Mark Cassidy    schedule 23.06.2011