Nous savons que créer un contrôle est généralement plus compliqué qu'un module qui implémente uniquement la même fonction, car nous devons prendre en compte davantage d'exceptions et d'adaptabilité pour obtenir l'effet d'intégration et de réutilisation du code. Et lorsque nous développons un contrôle ASP.NET, quelle que soit la complexité des fonctions et des performances de l'interface utilisateur de notre contrôle, ce que nous obtenons dans le navigateur client n'est qu'une combinaison de code HTML et de scripts.
Quant aux codes HTML générés par ces champs, leurs formats peuvent-ils être traités à volonté ? Alors, que signifie ne pas être libre ? Doit-on assurer le formatage du code HTML et maintenir une bonne indentation hiérarchique du HTML ? Au contraire ici, il faudrait essayer de supprimer tout ce qui n'a rien à voir avec le code HTML du champ, y compris les espaces "inutiles" et les retours chariot. Pourquoi insister sur l’inutile ? Nous savons que lorsque le navigateur traite le code source HTML, les espaces consécutifs et les retours chariot sont traités et affichés comme un seul espace. Par conséquent, il semble que nous n'ayons pas besoin de nous soucier des espaces inutiles supplémentaires ou des retours chariot avant, après ou au milieu du code HTML lorsque le contrôle ASP.NET est rendu. Jetons donc un œil à l'exemple suivant : <img id="analysisChart" src="ChartPic_000007.jpeg?B9FA64E7-2020-4430-AAF4-B20A51794909" usemap="#usemap_analysisChart">
<map id="usemap_analysisChart">
<zone>...<zone>
</carte>
'www.downcodes.com
L'extrait de code ci-dessus est le code HTML généré par le contrôle Web Chart dans Dundas Web Controls. Il ne semble y avoir aucun problème lors de l'utilisation de cette image graphique avec une zone chaude. Si vous utilisez simplement ce graphique seul, il n'y a en effet aucun problème. Mais lorsque nous combinons Dundas Chart dans un WebControl personnalisé, son code HTML avec sauts de ligne et indentation pose problème. En raison des besoins de mise en page, je dois placer ce graphique dans un tableau et faire en sorte que le tableau affiche une bordure de pixels entourant étroitement le graphique. À l'origine, l'apparence de ce graphique n'était qu'une image, et cette combinaison ne semblait poser aucun problème. Cependant, la situation réelle est que l'image du graphique ne pourrait jamais remplir le tableau extérieur (comme indiqué ci-dessous), et là. Il y avait toujours des espaces au bas de l'image et au bord inférieur du tableau. Il y a un espace de 3 à 4 pixels. Cet écart est dû à l'espace et au saut de ligne entre <img /> et <map> (bien qu'IE le traite uniquement comme un espace).
|
Étant donné que Dundas Web Chart est une DLL compilée publiée, il devient plus difficile de supprimer les espaces inutiles et les retours chariot dans le HTML qu'il génère. Nous pouvons uniquement supprimer le code HTML de son flux de rendu, puis supprimer manuellement les espaces et les retours chariot entre les balises, puis le sortir dans le flux de sortie du nouveau contrôle. Bien que cette méthode puisse résoudre certains problèmes, si les contrôles internes sont trop complexes, cela constituera une charge supplémentaire en termes de précision et d’efficacité.
Ainsi, à partir des questions ci-dessus, nous pouvons voir que lorsque nous créons un contrôle ASP.NET, le code HTML finalement rendu doit suivre le « principe de compacité du code » pour améliorer l'adaptabilité du contrôle. Selon ce principe, l'exemple précédent devrait ressembler à ceci :
<img id="analysisChart" src="ChartPic_000007.jpeg?B9FA64E7-2020-4430-AAF4-B20A51794909" usemap="#usemap_analysisChart"><map id="usemap_analysisChart"><area>...<area></ carte>
De cette façon, l’image du graphique est étroitement adjacente à la bordure du tableau qui l’entoure.