Question

De nombreuses discussions ont eu lieu sur les Moteurs de visualisation pour ASP.NET MVC, ainsi que des critiques à l'encontre du code & "; soupe-tag &" en ligne. avec des boucles fordops et des trucs du genre.

L'alternative ou le complément a été d'utiliser des assistants HTML, qui ne sont que des appels de méthodes inline.

Aujourd'hui, lorsque j'examine les assistants HTML d'ASP.NET MVC, ils utilisent une classe appelée TagBuilder .

Je propose d'utiliser LINQ to XML pour obtenir des caractères fortement typés et correctement mis en forme (X) HTML :

XDocument output = new XDocument();
XElement root = new XElement("div",
    new XAttribute("class", "root_item"));

XElement iconImage = new XElement("img",
    new XAttribute("src", ResolveUrl("~/image.gif")),
    new XAttribute("alt", "This is an image"));

XElement link = new XElement("a",
    new XAttribute("class", "link"),
    new XAttribute("href", "http://google.com"),
    new XText("Link to Google"));


root.Add(link);
root.Add(iconImage);
output.Add(root);

J'aime ça parce que c'est comme les contrôles fortement typés de WebForms, où vous pouvez créer un bouton et l'ajouter à la collection Control d'un autre contrôle.

Existe-t-il des problèmes ou des limitations apparents dans ce domaine?

Était-ce utile?

La solution

Je peux penser à deux problèmes à la méthode susmentionnée. Tout d'abord,

XElement iconImage = new XElement("img",
new XAttribute("src", ResolveUrl("~/image.gif")),
new XAttribute("alt", "This is an image"));

En vous référant à ce que vous écrivez ci-dessus, nous pouvons avoir quelque chose comme:

<img src=<%=whatever%> alt=<%=whatever%> />

Cela peut être un jugement personnel ou quoi, mais je vote certainement plus tard & "Human &"; lisible. Effectivement, utiliser LINQ 2 XML pourrait vous débarrasser de l'étrange & Lt;%}% & Gt; Cela errer dans mes pages aspx, mais en même temps, vous faites ces & "bons garçons &"; a l'air maladroit.

La deuxième pourrait être liée à un problème de performances. Je pense que l'analyse et l'exécution de LINQ 2 XML pourraient être assez lentes, bien que je n'ai aucune donnée à ce sujet.

Personnellement, je suis encore en train d’expérimenter le framework MVC, c’est comme revenir à l’ancien comme ASP ou PHP 3.X, car presque toutes les parties interactives sont gérées explicitement, au lieu des ASP Dot Net orientés fenêtre / GUI-OOP Cadre. Je pense que la raison principale pour laquelle je vais utiliser MVC est qu’il peut garantir la meilleure qualité possible des codes HTML côté client.

Autres conseils

C'est une bonne idée! Le seul problème que je vois avec cela est l'utilisation de C #. ;) VB.NET supporte beaucoup mieux la production de XML via sa fonctionnalité littérale XML.

Le code que vous listez dans votre question pourrait être écrit comme ceci dans VB.NET. (Avec l'ajout du texte & "Ceci est un lien &"; car votre exemple ne contient aucun texte dans l'élément a.)

Dim root = <div class="root_item">
               <img src=<%= ResolveUrl("~/image.gif") %> alt="This is an image"/>
               <a class="link" href="http://google.com">This is a link</a>
           </div>

Il existe encore <%= ... %> balises, mais leur validité est vérifiée au moment de la compilation. Si ce code est devenu la valeur renvoyée par une fonction renvoyant le type XElement, cet extrait de code Xhtml peut être réutilisé ailleurs sur le site.

J'ai un projet sur CodePlex qui utilise les littéraux XML VB.NET en tant que moteur de vue ASP.NET MVC personnalisé à l'adresse http: //vbmvc.codeplex.com . Il est basé sur le code Dmitry Robsman , qui est Product Unit Manager pour ASP.NET chez Microsoft. Les vues sont des classes VB.NET et les pages maîtres sont des classes de base. Vous new-up les classes de vue partielle au lieu de les référencer par une chaîne de nom, ce qui constitue également une vérification supplémentaire de la compilation. Au lieu de la classe HtmlHelper, qui retourne des chaînes, il existe une classe XhtmlHelper qui renvoie XElement et fonctionne de la même manière que ce que vous avez proposé.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top