Благоприятные для разработчика представления у Asp. Сетевой MVC
Ну, что, если один из Ваших клиентов говорит Вам восстанавливать к более ранней версии их данных из-за некоторого испорченного задания импорта или подобный? Вообразите, как Ваши клиенты чувствовали бы, сказали ли Вы им, что "не можете сделать этого, так как Ваши данные совместно используются всеми нашими клиентами" или "Извините, но Ваши изменения были потеряны, потому что клиент X потребовал восстановления базы данных".
4 ответа
Взгляните на Spark . Его синтаксис аналогичен вашему примеру.
Как сказал Чарльз Конвей, Spark определенно подходит. Посмотри на пример. Сначала вы создаете частичное представление в _ActionLink.spark с кодом:
<viewdata text="String" action="String" controller="String">
${ Html.ActionLink(controller, action, text) }
Затем вы используете его так же в других представлениях:
<ActionLink text="Home" action="Index" controller="Main" />
Вам просто нужно подготовить частичные представления для ваших дизайнеров, а затем они создают представление в предпочтительном стиле. Разве это не просто?
РЕДАКТИРОВАТЬ:
Извините, это было неправильно. не будет работать, потому что Home, Index и Main рассматриваются как переменные. Сделать это так, как вы хотите, может быть не так-то просто.
Пока ответили и приняли, я не вижу примера этого: почему бы вам просто не использовать:
Аналогично Spark. Я предпочитаю это Html.ActionLink, Html.BeginForm и т. Д., Когда это возможно (почти всегда, за исключением элементов управления формы, где проще иметь автоматическое кодирование имен с помощью помощников Html).
И ваши дизайнеры см. ссылка.
У меня есть аналогичное требование для текущего проекта, за исключением того, что мои «дизайнеры» в большей или меньшей степени являются конечными пользователями (людьми, которые разбираются в HTML, но это не их работа), что приводит к некоторым дополнительные задачи. Моя реализация, вероятно, слишком специфична для ваших нужд, но я быстро объясню ее, чтобы она не была полезна кому-либо еще.
Я хотел полностью избежать какого-либо кода в представлениях для страниц, которые они будут проектировать, поэтому я решил используйте систему шаблонов, которая делает что-то похожее на ваш пункт №2, но не во время выполнения. Я также использую Spark, хотя это не для пользы пользователей, поскольку они не будут касаться ничего, что выглядит как код.
В основном пользователи создают полный шаблон только для html, который имеет теги-заполнители для пользовательских элементов управления и частично Просмотры. Затем пользователи загружают шаблон через интерфейс, который анализирует его и превращает в искровое представление.
например.
Для галереи изображений разбирается во что-то вроде ! {Html.Gallery (Model)} или . Для поля описания разбирается в ! {Html.Description (Model, x => x.Descriptions.Kitchen)} . Он также проверяет, что «Кухня» на самом деле является свойством для объекта / страницы, на которую создается шаблон, или что Модель, передаваемая для галереи, на самом деле содержит коллекцию изображений, чтобы избежать ошибок времени выполнения.
Другие свойства могут быть указывается в теге для передачи дополнительных параметров анализируемым элементам управления. Если для указанного элемента управления требуется Javascript, он также включается в представление. Если есть проблемы с парсингом, вывод - это возврат, указывающий, какой заполнитель недействителен и почему.