Дизайнерские представления в Asp.Net MVC

Question

Мне нравится Asp.Net MVC и я хочу использовать его в предстоящем проекте. Тем не менее, часть проекта - это акцент на возможности представить проект «Представления» дизайнерам для таких вещей, как тематика и т. Д. Одна из проблем, которую я ожидаю, заключается в том, что представления Asp.Net MVC довольно ориентированы на разработчиков. Я действительно не хочу, чтобы обучить дизайнер на intracies в <% против <% = не говоря уже что-то вроде <% Еогеаспа ...

Возьмет типичную структуру меню MVC, например.

<div id="menu"> 
<ul> 
     <li><%= Html.ActionLink("Home", "Index", "Main")%></li> 
     <li><%= Html.ActionLink("About", "About", "Main")%></li> 
     <li><% Html.RenderPartial("LogOnUserControl"); %></li> 
    </ul> 
</div> 

Я бы предпочел быть в состоянии сказать дизайнерам идти с чем-то вроде

<div id="menu"> 
<ul> 
     <li>{ActionLink "Home", "Index", "Main"}</li> 
     <li>{ActionLink "About", "About", "Main"}</li> 
     <li>{Partial "LogOnUserControl"}</li> 
    </ul> 
</div> 

Или

<div id="menu"> 
<ul> 
     <li><my:ActionLink text="Home" action="Index" controller="Main" /></li> 
     <li><my:ActionLink text="About" action="About" controller="Main" /></li> 
     <li><my:Partial name="LogOnUserControl" /></li> 
    </ul> 
</div> 

Да, что последние выглядят подозрительно, как плот UserControls. Лично я не поклонник фактического использования UserControls для этого, хотя бы потому, что рендеринг этих элементов управления происходит после всего остального (как я понимаю), и я бы предпочел что-то, что больше соответствует жизненному циклу MVC , Все, что мне действительно нужно, это набор заполнителей и способ заменить их соответствующим рендерингом.

Итак, где лучшее место для этого и какие компромиссы я смотрю здесь. Я могу себе представить пару ракурсов:

• Пользовательский класс ViewPage, где я могу переопределить что-то важное. ViewPage.RenderView или ViewPage.FrameworkИнициализируйте, может быть, но как вы получаете текст оттуда, я не знаю.
• Создайте пользовательский TextWriter и переопределите ViewPage.CreateHtmlTextWriter, чтобы затем перехватить вывод текста для замены материала. Это довольно поздно в цикле, хотя, и будет возиться с другой пользовательской фильтрацией, если я не буду осторожен.
• Создайте собственные классы IView и ViewEngine. Я не ушел далеко по этому пути, прежде чем задаться вопросом, отправился ли я в очень плохое место.
• Пользовательские UserControls, которые могут имитировать необходимую функциональность.

Мнения? Другие варианты? Мой собственный ViewEngine мой лучший вариант? Моя собственная ViewPage? Или объекты UserControl будут адекватными (скажите нет)?

Answer 1

Взгляните на Spark. Синтаксис подобен вашему примеру.

Answer 2

Как сказал Чарльз Конвей, искра определенно способ пойти. Посмотрите на пример. Во-первых, вы создаете частичный вид в _ActionLink.spark с кодом:

<viewdata text="String" action="String" controller="String"> 
${ Html.ActionLink(controller, action, text) } 

Тогда вы используете его, как в других видах:

<ActionLink text="Home" action="Index" controller="Main" /> 

Вы просто должны подготовить частичный вид для дизайнеров и затем они создать представление в предпочтительном стиле. Не так ли?

EDIT:

К сожалению, это было не так.<ActionLink text="Home" action="Index" controller="Main" /> не будет работать, потому что Home, Index и Main обрабатываются как переменные. Возможно, это не так просто сделать, как вы пожелаете.

Answer 3

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

<li><a href='<%= Url.Action("Home", "Index")%>'>Main</a></li>

Похожие в Спарк. Я предпочитаю это Html.ActionLink, Html.BeginForm и т. Д., Когда это возможно (почти всегда, за исключением элементов управления формой, где проще иметь автоматическое кодирование имени с помощью помощников Html).

И ваши дизайнеры см. ссылку.

Answer 4

У меня есть аналогичное требование для текущего проекта, за исключением того, что мои «дизайнеры» - это более или менее конечные пользователи (люди, которые знают свой путь вокруг html, но это не их работа), что приводит к некоторым дополнительным проблемам. Моя реализация, вероятно, слишком специфична для ваших нужд, но я быстро объясню это, чтобы она не была полезной для кого-либо еще.

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

В основном пользователи создают полный шаблон только для html, который имеет метки тегов для пользовательских элементов управления и частичных представлений. Затем пользователи загружают шаблон через интерфейс, который анализирует его и превращает в искровое представление.

например. Для картинной галереи <gallery /> анализируется на что-то вроде !{Html.Gallery(Model)} или <use file="Gallery"/>. Для поля описания <desc name="Kitchen" /> разобран на !{Html.Description(Model, x => x.Descriptions.Kitchen)}. Он также проверяет, что «Кухня» на самом деле является свойством для шаблона объекта/страницы, или что модель, передаваемая в галерею, фактически содержит коллекцию изображений, чтобы избежать ошибок времени выполнения.

Другие свойства могут быть указаны в теге для передачи дополнительных параметров в синтаксические элементы управления. Если для указанного элемента управления требуется Javascript, он также включается в представление. Если есть какие-либо проблемы в анализе, вывод - это возврат, указывающий, какой заполнитель неверен и почему.