ASP.NET MVC 3 Assistants HTML personnalisés - Meilleures pratiques/Utilisations

Question

Nouveauté de MVC et ayant exécuté les tutoriels sur le site Web asp.net.

Ils incluent un exemple d'assistant html personnalisé pour tronquer le texte long affiché dans une table. Je me demandais simplement quelles autres solutions les gens ont trouvées avec des aides HTML et s'il y a des bonnes pratiques ou des choses à éviter lors de leur création/utilisation.

À titre d'exemple, je considérais écrire une aide personnalisée aux dates de format que je dois afficher dans différents endroits, mais je suis maintenant préoccupé qu'il peut y avoir une solution plus élégante (IE DataAnnotations dans mes modèles)

Des pensées?

EDIT:

Une autre utilisation potentielle que je viens de penser à ... concaténation String. Un assistant personnalisé peut saisir un ID utilisateur en entrée et renvoyer un nom complet aux utilisateurs ... Le résultat peut être une forme de (Titre) (Premier) (Moyen) (Dernier) en fonction de l'un de ces champs disponibles. Juste une pensée, je n'ai encore rien essayé de tel.

Answer 1

bien dans le cas de mise en forme l'attribut DisplayFormat pourrait être une bonne solution:

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

puis simplement:

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

En ce qui concerne la chaîne troncature est concerné une aide HTML personnalisé est un bonne solution.

---

MISE À JOUR:

concernant votre EDIT, un assistant HTML personnalisé pourrait fonctionner dans cette situation, mais il y a aussi une autre approche qui me plaît beaucoup: modèles de vue. Donc, si ce point de vue particulier, vous allez toujours montrer la concaténation des noms que vous pouvez alors définir un modèle de vue:

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

Maintenant, le régulateur va interroger le référentiel pour aller chercher le modèle et la carte ce modèle à un modèle de vue qui sera passé à la vue de sorte que la vue pourrait simplement @Html.DisplayFor(x => x.FullName). Le mappage entre les modèles et les modèles de vue pourrait être simplifié avec des frameworks comme AutoMapper.

Answer 2

J'utilise HtmlHelpers tout le temps, le plus souvent pour encapsuler la génération de HTML standard, au cas où je changerais d'avis. J'ai eu des helpers tels que:

• Html.BodyId(): génère un tag d'identification de corps conventionnel pour le référencement lors de l'ajout de CSS personnalisé pour une vue. Html.SubmitButton (string): génère un élément d'entrée [type = submit] ou un bouton [type = submit], en fonction de la façon dont je veux styliser les boutons.
• Html.Pager (IPagedList): pour générer des commandes de pagination à partir d'un modèle de liste paginée.
• etc ....

L'une de mes utilisations préférées pour HtmlHelpers est de sécher le balisage de formulaire commun. Habituellement, j'ai un conteneur div pour une ligne de formulaire, un div pour l'étiquette, et un label pour l'entrée, les messages de validation, le texte d'indice, etc. En fin de compte, cela pourrait se traduire par beaucoup de tags html. Un exemple de la façon dont je me suis occupé ce qui suit:

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... 
}  

Une fois que vous avez fait cela, cependant, vous pouvez forment des lignes de sortie comme celle-ci:

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

... et BAM, toutes vos étiquettes , les entrées, les astuces et les messages de validation sont sur votre page. Encore une fois, vous pouvez utiliser des attributs sur vos modèles et réfléchir sur eux pour devenir vraiment intelligent et sec. Et bien sûr, ce serait une perte de temps si vous ne pouvez pas standardiser votre conception de formulaire. Cependant, pour les cas simples, où css peut fournir toute la personnalisation dont vous avez besoin, cela fonctionne grrrrrrrrreat!

Morale de l'histoire - HtmlHelpers peut vous isoler des changements de conception globaux en détruisant le balisage fabriqué à la main dans la vue après vue. Je les aime. Mais vous pouvez aller trop loin, et parfois les vues partielles sont meilleures que les aides codées. Une règle générale que j'utilise pour choisir entre une vue auxiliaire et une vue partielle: Si le morceau de HTML nécessite beaucoup de logique conditionnelle ou de tromperie de codage, j'utilise une aide (mettre le code où le code devrait être); sinon, si je ne fais que sortir un balisage commun sans beaucoup de logique, j'utilise une vue partielle (mettre un balisage là où le balisage devrait être).

J'espère que cela vous donnera quelques idées!