ASP.NET MVC 3 Ayudantes HTML personalizados- Mejores prácticas/Usos

Question

Nuevo en MVC y hemos estado ejecutando los tutoriales en el sitio web asp.net.

Incluyen un ejemplo de un ayudante html personalizado para truncar el texto largo que se muestra en una tabla.

Solo me pregunto qué otras soluciones han encontrado las personas al usar ayudantes de HTML y si hay algunas mejores prácticas o cosas para evitar al crearlas/usarlas.

A modo de ejemplo, yo estaba considerando escribir un ayudante a medida para las fechas de formato que necesito para mostrar en varios lugares, pero ahora estoy preocupado de que puede haber una solución más elegante (DataAnnotations es decir, en mis modelos)

¿Alguna idea?

EDIT:

Otro uso potencial me acaba de ocurrir ... concatenación de cadenas. Un asistente personalizado podría tomar un ID de usuario como entrada y devolver un nombre completo de usuario ... El resultado podría ser alguna forma de (Título) (Primero) (Medio) (Último) dependiendo de cuáles de esos campos están disponibles. Sólo un pensamiento, todavía no he intentado algo como esto.

Answer 1

bien en el caso de formatear el atributo DisplayFormat podría ser una buena solución:

[DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}")] 
public DateTime Date { get; set; } 

y luego simplemente:

@Html.DisplayFor(x => x.Date) 

En lo que truncar la cadena se refiere a un ayudante HTML personalizado es una buena solución.

---

ACTUALIZACIÓN:

cuanto a su edición, un ayudante HTML personalizada podría funcionar en esta situación, pero también hay un enfoque alternativo que me gusta mucho: modelos de vista. Así que si en este punto de vista particular, siempre se va a mostrar la concatenación de los nombres entonces se podría definir una vista de modelo:

public class PersonViewModel 
{ 
    public string FullName { get; set; } 
} 

Ahora el controlador va a consultar el diccionario para buscar el modelo y luego asignar este modelo a un modelo de vista que se pasará a la vista para que la vista pueda simplemente @Html.DisplayFor(x => x.FullName). El mapeo entre modelos y modelos de vista podría simplificarse con marcos como AutoMapper.

Answer 2

Uso HtmlHelpers todo el tiempo, más comúnmente para encapsular la generación de HTML estándar, en caso de que cambie de opinión. He tenido asistentes como:

• Html.BodyId(): genera una etiqueta de identificación corporal convencional para hacer referencia cuando se agrega CSS personalizado para una vista.
• Html.SubmitButton (cadena): genera un elemento de entrada [type = submit] o button [type = submit], dependiendo de cómo quiera aplicar estilo a los botones.
• Html.Pager (IPagedList): para generar controles de paginación desde un modelo de lista paginada.
• etc ....

Uno de mis usos favoritos para HtmlHelpers es SECAR el marcado de formulario común. Por lo general, tengo un contenedor div para una línea de formulario, un div para la etiqueta y una etiqueta para la entrada, mensajes de validación, texto de sugerencia, etc. En última instancia, esto podría terminar siendo un montón de etiquetas html repetitivas. Un ejemplo de cómo he manejado esto sigue:

public static MvcHtmlString FormLineDropDownListFor<TModel, TProperty>(this HtmlHelper<TModel> helper, Expression<Func<TModel, TProperty>> expression, IEnumerable<SelectListItem> selectList, string labelText = null, string customHelpText = null, object htmlAttributes = null) 
{ 
    return FormLine(
     helper.LabelFor(expression, labelText).ToString() + 
     helper.HelpTextFor(expression, customHelpText), 
     helper.DropDownListFor(expression, selectList, htmlAttributes).ToString() + 
     helper.ValidationMessageFor(expression)); 
} 

public static MvcHtmlString FormLineEditorFor<TModel, TProperty>(this HtmlHelper<TModel> helper, Expression<Func<TModel, TProperty>> expression, string templateName = null, string labelText = null, string customHelpText = null, object htmlAttributes = null) 
{ 
    return FormLine(
     helper.LabelFor(expression, labelText).ToString() + 
     helper.HelpTextFor(expression, customHelpText), 
     helper.EditorFor(expression, templateName, htmlAttributes).ToString() + 
     helper.ValidationMessageFor(expression)); 
} 

private static MvcHtmlString FormLine(string labelContent, string fieldContent, object htmlAttributes = null) 
{ 
    var editorLabel = new TagBuilder("div"); 
    editorLabel.AddCssClass("editor-label"); 
    editorLabel.InnerHtml += labelContent; 

    var editorField = new TagBuilder("div"); 
    editorField.AddCssClass("editor-field"); 
    editorField.InnerHtml += fieldContent; 

    var container = new TagBuilder("div"); 
    if (htmlAttributes != null) 
     container.MergeAttributes(new RouteValueDictionary(htmlAttributes)); 
    container.AddCssClass("form-line"); 
    container.InnerHtml += editorLabel; 
    container.InnerHtml += editorField; 

    return MvcHtmlString.Create(container.ToString()); 
} 

public static MvcHtmlString HelpTextFor<TModel, TProperty>(this HtmlHelper<TModel> helper, Expression<Func<TModel, TProperty>> expression, string customText = null) 
{ 
    // Can do all sorts of things here -- eg: reflect over attributes and add hints, etc... 
}  

Una vez hecho esto, sin embargo, se puede formar líneas de salida como esta:

<%: Html.FormLineEditorFor(model => model.Property1) %> 
<%: Html.FormLineEditorFor(model => model.Property2) %> 
<%: Html.FormLineEditorFor(model => model.Property3) %> 

... y BAM, todas las etiquetas , entradas, sugerencias y mensajes de validación están en su página. Nuevamente, puede usar atributos en sus modelos y reflexionar sobre ellos para ser realmente inteligente y SECO. Y, por supuesto, esto sería una pérdida de tiempo si no puede estandarizar el diseño de su formulario. Sin embargo, para casos simples, donde css puede proporcionar toda la personalización que necesita, ¡funciona grrrrrrrrrreat!

Moraleja de la historia: HtmlHelpers puede aislarlo de los cambios en el diseño global arruinando el marcado hecho a mano a la vista después de la vista. Me gustan. Pero puedes ir por la borda, y a veces las vistas parciales son mejores que las de los ayudantes codificados. Una regla general que utilizo para decidir entre helper vs. partial view: si el fragmento de HTML requiere mucha lógica condicional o trucos de codificación, uso un helper (ponga el código donde debería estar el código); si no, si solo estoy produciendo un marcado común sin mucha lógica, uso una vista parcial (ponga el marcado donde debería estar el marcado).

¡Espero que esto te dé algunas ideas!