Pull to refresh

Comments 6

От имени всего Sitecore Customer Service спрашиваю «Зачем»? Реализация сложная. последствия у этого могут быть неприятные, а очевидных преимуществ не видно.
Всё это скорее для того, чтобы облегчить саппорт сайтов. Мы саппортим ворох сайтов, написанных неведомо кем и неведомо когда. И очень популярная проблема — есть константы с именами филдов, но есть также и куча полей прописанных в коде и в разметке. Я очень надеюсь, что наш сложный подход затруднит замусоривание проекта, и через пару лет люди смогут понять, и расширить существующую структуру темплейтов.
Я как облегчается саппорт сайтов? По-моему опыту в случае грамотной архитектуры сайта замусоривания и так не происходит, а предложенное решение выступает, скорее в роли костыля. Более того система кеширования может работать непредсказуемо в таком случае. Про масштабирование (CM и CD сервер) я вообще молчу. Ну и апгрейдиться до более поздней (а 6.3 уже довольно старая версия) версии Сайткора может быть сложно.
Если вам так хочется mvc — подобного подхода, использовали бы Сайткор 6.5 и Sitecore mvc.
Обязательно использовали бы 6.5 если бы могли. На имеющимся у заказчика инстансе сайткора 6.3 уже функционирует несколько сайтов и апгрейдить всё это хозяйство до 6.5 — действительно сложно. Про масштабирование зря молчите, всё успешно работает на связке из 4х или 5ти серверов.

Вы бы посоветовали использовать кучи FieldRenderer-ов и проверки типа if (item!=null && item[«my nice key»] != null) на каждой странице, а также набор строковых констант в каком-либо виде? Или же вы бы использовали какой-то действительно удобный генератор модели, о котором я не знаю?
Добавлю: сложна реализация только нескольких базовых классов, а вот код конкретных станиц выглядит гораздо понятнее и проще.
Да, замысел не совсем понятен. Может быть выложите хотя бы куда-нибудь? Погоняем на нашем добре :)
Sign up to leave a comment.

Articles