Создание содержащего элемента, свойства которого могут влиять на отображение дочерних элементов - PullRequest
0 голосов
/ 12 января 2012

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

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

(Для усложнения вещей есть одно поле для комментариев, которое можно редактировать, даже если все остальные поля доступны только для чтения, поэтому будет сообщение назад.)

Я думаю об общем решении этой проблемы. Самое простое, что можно сделать, это применить следующий шаблон кода ко всем полям:

@{ if(condition) {
   @Html.TextBoxFor(model=>model.Field)
}
else 
{
   @Html.DisplayFor(model=>model.Field)
}
}

Но это не элегантно и может затруднить чтение кода. Кроме того, так как шаблон должен быть применен вручную, было бы легко делать ошибки.

Я занимался написанием некоторых методов расширения для дополнения TextBoxFor и др., Которые бы принимали дополнительный параметр, указывающий, вызывать ли TextBoxFor или DisplayFor.

Но то, что я хотел бы еще лучше, - это то, что я мог бы установить для содержащего элемента, который бы автоматически влиял на способ отображения дочерних элементов, а также на способ установки свойства Visible в элементе управления ASP.NET WebForms Panel.

Так что теперь я выхожу в область гипотетических. Чтобы достичь этого, мне понадобится элемент, содержащий серверную часть (возможно, следуя тому же шаблону, что и BeginForm), который знает о своей собственной области и может влиять на то, как вызывались содержащиеся в нем вызовы расширения рендеринга.

Такое вообще возможно?

Ответы [ 2 ]

0 голосов
/ 12 января 2012

Я не на самом деле рекомендую это, но вы могли бы сделать что-то вроде этого:

    public static MvcHtmlString Ternary<TModel, TValue>(this HtmlHelper<TModel> html, bool test, Expression<Func<TModel, TValue>> expression, Func<Expression<Func<TModel, TValue>>, MvcHtmlString> truthy, Func<Expression<Func<TModel, TValue>>, MvcHtmlString> falsey)
    {
        return ((test) ? truthy : falsey).Invoke(expression);
    }

и затем использовать это так:

 @Html.Ternary(condition, x => x.Field, Html.TextBoxFor, Html.DisplayFor));

Отдельные виды, как сказала Акула, действительно, вероятно, правильный путь.

0 голосов
/ 12 января 2012

Я бы посмотрел на этот пост: http://kazimanzurrashid.com/posts/asp-dot-net-mvc-viewmodel-usage-and-pick-your-best-pattern

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

...