Contrôles par rapport au HTML standard
https://stackoverflow.com/questions/22084
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je me lance dans ASP.NET (C# - je sais que cela n'a pas d'importance pour cette question particulière, mais la divulgation complète et tout ça), et même si j'aime le fait que le asp:-les contrôles de style m'évitent beaucoup de tâches fastidieuses de création HTML, je suis souvent frustré par certains comportements.J'en ai rencontré un hier soir en travaillant avec des pages maîtres :mon <asp:BulletedList ID="nav">, une fois converti en HTML, est devenu <ul id="ct100_nav">.
Il existe d'autres problèmes : j'ai remarqué que lorsque vous remplissez automatiquement un DataGrid, cela ajoute à la table résultante des attributs que je ne souhaite pas nécessairement.
Je sais qu'il y a un certain nombre de "conventions sur la configuration" que vous devez accepter lorsque vous comptez sur un framework pour prendre en charge certaines de vos tâches fastidieuses, mais les "conventions" dans ces cas ne sont pas vraiment des conventions établies. , mais plutôt des extras inutiles.Je sais pourquoi l'ID ajoute le préfixe, mais je devrais pouvoir modifier et désactiver des choses comme celle-ci, d'autant plus que, en tant qu'évangéliste des standards du Web, je ne duplique pas de toute façon les identifiants HTML sur une seule page.
La question ici s'adresse donc aux développeurs ASP.NET plus expérimentés que moi :D'après vos expériences en matière de développement et de déploiement d'applications, comment exploitez-vous ces contrôles ?Avez-vous recours au HTML codé en dur ?Utilisez-vous un mélange ?Je ne veux pas concevoir mon code HTML autour de bizarreries idiosyncratiques de ces contrôles, mais, si possible, j'aimerais les exploiter lorsque cela est possible.
Qu'est-ce qu'un garçon doit faire ?
La solution
Personnellement,
Je pense que les contrôles ASP.NET standard conviennent aux tâches internes - rapides et sales sont bons dans ce scénario.Mais j'ai déjà travaillé avec un développeur Web qui était également concepteur et il a refusé d'utiliser les contrôles ASP.NET et de coder uniquement en HTML et d'ajouter des balises runat="server" si nécessaire.C'était davantage parce qu'il voulait savoir exactement comment son HTML allait être rendu, et à l'époque de toute façon, certains contrôles ASP.NET ne seraient pas rendus conformément aux normes.
Je suis assis quelque part au milieu - utilisez HTML lorsque cela est approprié et non lorsque ce n'est pas le cas.Vous pouvez en quelque sorte profiter du meilleur des deux mondes avec le Adaptateurs de contrôle CSS
Autres conseils
Je suis en fait assez soulagé de voir ici certaines opinions qui concordent avec les miennes :ASP.NET en tant que langage de modèle est très médiocre.
Je voudrais juste réfuter quelques points positifs avancés ici (combinaison de flammes !) :
Dave Ward mentionne les collisions d'identité - c'est vrai, mais à quel point c'est mal géré.J'aurais préféré voir les nœuds référencés par des sélecteurs XPath ou Deep CSS plutôt qu'en rendant l'ID effectivement inutile, sauf en m'en remettant aux composants internes d'ASP.NET comme clientID - cela rend simplement l'écriture de CSS et JS encore plus difficile et inutile.
Rob Cooper explique que les contrôles remplacent le HTML, donc tout va bien (paraphrasant, pardonnez-moi Rob) - eh bien, ce n'est pas bien, car ils ont pris un langage existant et bien compris et ont dit "non, vous devez faire les choses à notre manière". maintenant", et leur chemin est très mal mis en œuvre.par exemple.asp:panel affiche une table dans un navigateur et un div dans un autre !Sans documentation ni exécution, le balisage d'un contrôle de connexion (et bien d'autres) n'est pas prévisible.Comment allez-vous amener un concepteur à écrire du CSS contre cela ?
Espo écrit sur la façon dont les contrôles vous offrent les avantages de l'abstraction si la plate-forme modifie le code HTML - eh bien, c'est clairement circulaire (cela ne change que parce que la plate-forme change, et cela n'aurait pas été nécessaire si j'avais simplement mon propre code HTML à la place) et crée effectivement un problème.Si le contrôle doit à nouveau changer avec les mises à jour, comment mon CSS est-il censé gérer cela ?
Les apologistes diront "oui mais vous pouvez changer cela dans la configuration" ou parleront de contrôles prioritaires et de contrôles personnalisés.Eh bien, pourquoi devrais-je le faire ?Le package de contrôles compatibles CSS destiné à résoudre certains de ces problèmes est tout sauf avec son balisage non sémantique et il ne résout pas le problème d'identification.
Il est impossible d'implémenter MVC (le concept abstrait, pas l'implémentation 3.5) directement avec des applications de formulaire Web, car ces contrôles lient si étroitement la vue et le contrôle.Il existe désormais une barrière à l'entrée pour le concepteur de sites Web traditionnel, car il doit s'impliquer dans le code côté serveur pour implémenter ce qui était autrefois les domaines distincts CSS et JS.Je sympathise avec ces gens.
Je suis tout à fait d'accord avec le point de Kiwi selon lequel les contrôles permettent un développement très rapide pour les applications d'un certain profil, et j'accepte que, pour une raison quelconque, certains programmeurs trouvent le HTML désagréable, et en outre que les avantages que les autres parties d'ASP.NET vous offrent, qui nécessite ces contrôles, peut ça vaut le prix.
Cependant, je je n'apprécie pas la perte de contrôle, je pense que le modèle consistant à gérer des éléments tels que les classes, les styles et les scripts sur le code-behind est un mauvais pas en arrière, et je pense en outre qu'il existe de meilleurs modèles pour les modèles (implémentation de microformats et xslt pour cette plate-forme) bien que remplacer les contrôles par ceux-ci ne soit pas trivial.
Je pense qu'ASP.NET pourrait apprendre beaucoup des technologies associées dans le monde LAMP et Rails, d'ici là, j'espère travailler avec 3.5 MVC là où je peux.
(désolé, c'était si long </rant>)
La réponse courte est que vous ne devriez jamais utiliser un asp :...version d'un contrôle HTML standard, sauf si vous avez une très bonne raison.
Les développeurs juniors sont souvent amenés à utiliser ces contrôles car ils sont traités dans la plupart des livres ASP.NET, on suppose donc qu'ils doivent être meilleurs.Ils ne sont pas.À ce stade, après 8 ans de développement quotidien d'ASP.NET, je ne peux penser qu'à 2 ou 3 cas où il est réellement logique d'utiliser un asp :...Contrôle INPUT sur un contrôle HTML standard.
Quant aux ID sur les contrôles du serveur :Vous pouvez trouver l'ID réel qui va être écrit dans le navigateur en accédant à ClientID.De cette façon, vous pouvez combiner les scripts côté serveur et côté client sans avoir à coder en dur _id="ct100_nav"_
J'essaie toujours d'utiliser les contrôles inclus au lieu de "pirater" le HTML, car s'il y a une mise à jour ou une amélioration ultérieure, tout mon code fonctionnera toujours en remplaçant simplement le framework et je n'aurai pas à modifier le code HTML.
J'espère que cela t'aides
@Brian, yup!Vous pouvez à peu près contrôler tous les comportements.Pensez à créer des contrôles personnalisés (il existe trois types).J'en ai récemment donné un aperçu dans ma question ici.
Je voudrais fortement Je vous recommande de les consulter, cela m'a aidé sans fin :)
Moi aussi, je suis dans mon aventure dans ASP.NET et j'ai également eu des frustrations similaires.Cependant, on s'y habitue vite.Tu as juste besoin de te rappeler, la raison pour laquelle vous n'avez pas la fastidieuse création HTML est que les contrôles ASP.NET font tout pour vous.
Dans une certaine mesure, vous pouvez contrôler/modifier ces choses, même si cela signifie hériter du contrôle et peaufiner la sortie HTML à partir de là.
J'ai dû le faire dans le passé, lorsque certains contrôles ne passaient pas la validation du W3C par défaut en mettant un balisage supplémentaire ici et là, j'ai donc simplement remplacé et modifié si nécessaire (un correctif qui ne prend que quelques minutes).
Je dirais d'apprendre comment fonctionne le système de contrôle.Ensuite, rassemblez-en quelques-uns vous-même, cela m'a vraiment aidé à comprendre ce qui se passe sous le capot, donc si jamais j'ai des problèmes, j'ai une idée où aller.
Le HTML s'affiche avec ce type d'ID, car c'est le moyen utilisé par ASP.NET pour empêcher les collisions d'ID.Chaque contrôle conteneur, tel qu'une page maître ou un contrôle Assistant, ajoutera un « ID_ » sur les ID de ses enfants.
Dans le cas de votre liste à puces, ListView constitue un bon compromis.Vous pouvez toujours le lier à une source de données, mais cela vous donne un contrôle beaucoup plus strict sur le HTML rendu.Scott Gu a une belle introduction à ListView ici :
Si le préfixe de l'ID ajouté par ASP.NET est un problème pour que vous puissiez y accéder plus tard en utilisant JS ou quelque chose du genre...vous avez le côté serveur de propriété .ClientID.
Si la surcharge est ajoutée par ASP.NET, vous devriez envisager ASP.NET MVC (toujours en aperçu) où vous avez un contrôle total sur le code HTML émis.
Je passe à MVC parce que je n'aime pas non plus tous ces éléments ajoutés....
Je pense que la plupart des réponses ici adoptent le point de vue d'un concepteur.Sur un projet de petite à moyenne taille, cela peut sembler une surcharge de synchroniser le code et CSS/HTML et de les rendre propres et conformes aux normes.La façon dont un concepteur y parvient est d'avoir un contrôle total sur le rendu HTML.Mais il existe de nombreuses façons d’obtenir ce contrôle total dans ASP.NET.Et pour moi, avoir le code HTML requis dans le fichier aspx/ascx est la manière la plus non évolutive et la plus sale de le faire.Si vous souhaitez styliser les contrôles via CSS, vous pouvez toujours définir une classe côté serveur via la propriété CssClass.Si vous souhaitez y accéder via JS, vous pouvez à nouveau émettre le JS avec les bons identifiants côté serveur.Le seul inconvénient que cela présente est qu’un développeur et un concepteur doivent travailler en étroite collaboration.Sur tout grand projet, cela est de toute façon inévitable.Mais les avantages offerts par ASP.NET dépassent de loin ces difficultés.Néanmoins, si vous souhaitez que du HTML conforme aux normes, une prise en charge du skinning et d'autres avantages contrôlent le balisage rendu, vous pouvez toujours utiliser des contrôles tiers.
Comme Dave Ward l'a déjà mentionné, "c'est le moyen utilisé par ASP.NET pour empêcher les collisions d'ID".
Un très bon exemple de ceci est que si vous essayez de placer un contrôle à l'intérieur d'un contrôle personnalisé, utilisez ce contrôle personnalisé dans un répéteur, de sorte que le code HTML du contrôle personnalisé soit affiché plusieurs fois pour la page.
Comme d'autres l'ont mentionné, si vous avez besoin d'accéder aux contrôles pour javascript, utilisez la propriété ClientScript qui vous donnera accès à un ClientScriptManager et enregistrez vos scripts sur la page de cette façon.Assurez-vous, lorsque vous écrivez vos scripts, d'utiliser la propriété ClientID sur le contrôle que vous essayez de référencer au lieu de simplement saisir l'ID du contrôle.
Si vous souhaitez autant de contrôle sur le HTML rendu, consultez ASP.NET MVC plutôt.
