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

Question

Я наслаждаюсь Asp.Net MVC и собираюсь использовать его в будущем проекте. Часть проекта, однако, делает акцент на возможности представления представлений проекта дизайнерам для таких вещей, как тематика и так далее. Одна проблема, которую я ожидаю, заключается в том, что представления Asp.Net MVC скорее ориентированы на разработчиков. Я действительно не хочу обучать дизайнеров внутренностям <% vs. <% =, не говоря уже о чем-то вроде <% foreach ... </p>

Возьмем типичную структуру меню 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.FrameworkInitialize, возможно, но как вы узнаете текст, я не знаю.
• Создайте пользовательский TextWriter и переопределите ViewPage.CreateHtmlTextWriter, чтобы я мог затем перехватить текстовый вывод для замены материала. Это довольно поздно в цикле, и, если я не буду осторожен, он испортит другие пользовательские фильтры.
• Создание моих собственных классов IView и ViewEngine. Я не продвинулся далеко по этому пути, прежде чем подумать, направляюсь ли я в очень плохое место.
• Пользовательские пользовательские элементы управления, которые могут имитировать необходимые функции.

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

Answer 1

Взгляните на Spark . Его синтаксис похож на ваш пример.

Answer 2

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

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

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

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

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

Answer 3

Как сказал Чарльз Конуэй, «Спарк» определенно подходит. Посмотри на пример. Сначала вы создаете частичное представление в _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 4

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

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

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

А ваши дизайнеры видят ссылку.