Résumé : Cet article explique comment implémenter diverses fenêtres contextuelles à l'aide de CodeBehind dans ASP.NET et interagir avec les fenêtres contextuelles. Il aborde également les différents comportements de filtrage des navigateurs IE non standard couramment utilisés pour les fenêtres contextuelles et les contre-mesures correspondantes pour l'utilisation des fenêtres contextuelles, afin de fournir une solution universelle et meilleure pour l'utilisation des fenêtres contextuelles.
Mots-clés : ASP.NET, CodeBehind, filtrage, interface COM, JavaScript, liaison.
En tant que dernier outil de Microsoft pour créer des sites Web dynamiques, ASP.NET a fait de grands progrès en modifiant la méthode de programmation Web d'origine par rapport à ASP et JSP. Sa technologie de séparation de code et de page (CodeBehind) et ses contrôles complets de serveur Web offrent aux programmeurs une méthode de développement côté serveur Web plus conforme à la programmation traditionnelle. Cependant, la programmation Web présente toujours des caractéristiques différentes de la programmation traditionnelle. Ces caractéristiques déterminent que certaines techniques spéciales doivent être utilisées dans la programmation ASP.NET pour répondre aux exigences du programme. Les fenêtres contextuelles sont représentatives de ce type de méthode de programmation. De nombreux livres de programmation restent silencieux sur les fenêtres pop-up ou les mentionnent simplement en un seul mot, semblant ne pas comprendre l'immense monde d'utilisation des fenêtres pop-up. Cet article résoudra pour vous la plupart des problèmes liés à l’utilisation des fenêtres contextuelles.
Afin d'améliorer la concurrence et le débit de l'accès aux sites Web, ASP.NET, comme d'autres scripts serveur, utilise également des scripts côté client pour réduire la pression sur le serveur. ASP.NET ne prend pas directement en charge les fenêtres contextuelles jusqu'à présent (version 1.1), et les fenêtres contextuelles côté client doivent être utilisées via JavaScript (ou VBScript).
1. Fenêtre d'avertissement et méthode d'utilisation du script côté client dans CodeBehind
Pour afficher la fenêtre d'avertissement la plus simple dans le navigateur, vous pouvez utiliser l'instruction JavaScript :
window.alert([sMessage])
où sMessage est le message d'invite. Malheureusement, une telle fenêtre contextuelle n'a qu'un bouton « OK » et ne peut servir que d'invite. Si nous voulons faire apparaître une fenêtre contextuelle de requête lors de la suppression d'un enregistrement, vous devez utiliser :
bConfirmed = window.confirm([sMessage])
où : bConfirmed est la valeur de retour et sMessage est le message d'invite. Cette fenêtre pop-up propose deux options : "OK" ou "Abandonner", et la valeur de retour de son choix est placée dans bConfirmed pour que le code puisse porter un jugement.
Afin d'améliorer la réutilisabilité et la lisibilité du code, JavaScript et Codehind doivent être intégrés l'un à l'autre. Il existe généralement deux manières d’obtenir cet effet.
(1) Utilisez la méthode Response.Write :
L’utilisation de la méthode Response.Write a été prise en charge dès l’ère ASP. Il peut écrire du code pour le client, ce qui constitue une méthode très pratique et intuitive. Le code suivant montre comment utiliser la méthode Response.Write pour afficher un message d'avertissement.
Private Sub btAlert_Click (expéditeur ByVal en tant que System.Object, ByVal et en tant que System.EventArgs) gère btAlert.Click
' Illustre la méthode Response.Write et la fenêtre d'alerte.
Réponse.Write(" ")
End Sub
(2) Utilisez la méthode RegisterXXX
Si vous observez le code HTML généré par Response.Write, vous constaterez que le code généré par la méthode Response.Write est écrit au tout début du code HTML, c'est-à-dire avant. l'étiquette. Pour le moment, tous les objets HTML n'ont pas encore été générés. Si vous souhaitez utiliser et interagir avec des objets en HTML, une erreur « objet non trouvé » se produira. Par conséquent, l'auteur recommande une méthode plus conforme à la méthode CodeBehind, en utilisant la méthode RegisterXXX. RegisterXXX comprend : RegisterClientScriptBlock, RegisterStartupScript et la fonction IsStartupScriptRegistered pour le jugement.
Le prototype de RegisterStartupScript est :
Overridable Public Sub RegisterStartupScript( _
Clé ByVal sous forme de chaîne, _
Script ByVal en tant que chaîne _
)
où : key représente l'identifiant unique de ce script et script est une chaîne représentant le script.
Le prototype de RegisterClientScriptBlock est le même que RegisterStartupScript. La différence entre les deux fonctions est que le code de script qu'elles contiennent est écrit à des emplacements différents dans le fichier HTML. RegisterClientScriptBlock émet le script client immédiatement après la balise d'ouverture de l'élément de l'objet Page, et RegisterStartupScript émet le script avant la balise de fermeture de l'élément de l'objet Page. Si votre script contient des instructions qui interagissent avec l'objet page (objet document) (cela sera vu dans nos exemples ultérieurs), il est recommandé d'utiliser RegisterStartupScript. En revanche, si vous souhaitez que le script client soit exécuté le plus tôt possible. possible, vous pouvez utiliser RegisterClientScriptBlock ou Response.Write.
Afin d'éviter l'ajout répété de scripts à la page, ReisterStartupScript/RegisterClientScriptBlock utilise key comme clé d'enregistrement lors de l'enregistrement du script, puis IsClientScriptBlockRegistered peut être utilisé pour porter des jugements dans le programme.
L'exemple suivant utilisera RegisterClientScriptBlock pour démontrer l'utilisation de confirm.
Private Sub btConfirm_Click (ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btConfirm.Click
'Démontrer la méthode RegisterClientScriptBlock et confirmer windowIf
(Not IsClientScriptBlockRegistered("clientScript")) Then
'Déterminez si le script a été ajouté, sinon, ajoutez-le.
Dim strScript en tant que chaîne
strScript = " "
'Enregistrer scriptRegisterClientScriptBlock("clientScript", strScript)
'Si vous sélectionnez "Non", poursuivez l'exécution.
End If
End Sub
2. Afficher la page spécifiée
Le simple fait d'avoir une fenêtre d'invite est loin de répondre à nos exigences. Dans le programme, nous devons souvent afficher la page spécifiée. Pour le moment, vous pouvez utiliser la méthode window.open de JavaScript. Avec la méthode précédente RegisterClientSciptBlock, nous pouvons afficher la page spécifiée.
Le code suivant montre comment afficher la page spécifiée :
Private Sub btWinOpen_Click (ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btWinOpen.Click
'Utilisez window.open et registerStartupScript pour une démonstration simple.
Si (Not IsClientScriptBlockRegistered("OpenScript")) Alors
'Déterminez si le script a été ajouté, sinon, ajoutez-le.
Dim strScript As String = " "
RegisterStartupScript("OpenScript", strScript)
Fin si
End Sub
utilise la méthode Window.open pour afficher une nouvelle page, qui n'a qu'un seul paramètre : l'adresse URL de la nouvelle fenêtre contextuelle. Il s'avère que la méthode window.open a plusieurs paramètres, mais c'est une simple question de javascipt et nous n'entrerons pas dans les détails ici. Si vous avez des questions connexes, veuillez consulter MSDN.
Ce programme fonctionne bien lorsqu'il est utilisé directement dans IE. Mais si vous utilisez des navigateurs tels que GoSurf, MyIE2, NetCapter, etc., malheureusement ! Vous ne verrez pas de pop-ups. C'est ce dont nous allons discuter à propos du filtrage des pop-ups.
3. Discutez du comportement de filtrage des fenêtres contextuelles des navigateurs IE non standard.
La prolifération des fenêtres publicitaires a rendu de nombreux internautes insupportables d'être harcelés par les publicités. Ils ont abandonné les navigateurs IE standard et ont utilisé des navigateurs tels que GoSurf, MyIE2, et NetCapter qui utilisent le noyau IE pour prendre en charge plusieurs pages et un logiciel qui bloque automatiquement les publicités. On dit que dans le prochain IE6 sp2, Microsoft ajoutera également la fonction de blocage des fenêtres publicitaires. C'est bien sûr une bonne chose pour la plupart des utilisateurs d'Internet, mais pour les programmeurs, la façon dont nous utilisons les fenêtres contextuelles n'est pas fondamentalement différente des publicités ordinaires. De telles fenêtres seront également bloquées sans discernement par le gestionnaire de fenêtres contextuelles. bien sûr, nous ne voulons pas le voir. Existe-t-il un moyen standard de faire apparaître la fenêtre normalement ? Cela nous oblige à comprendre le principe du blocage de la publicité par le navigateur. Les bloqueurs de publicités courants utilisent les trois méthodes suivantes pour filtrer les publicités :
(1) Méthode de blocage basée sur le titre des fenêtres.
Le principe de cette méthode de blocage est de vérifier régulièrement tous les titres des fenêtres d'IE, puis de les filtrer en fonction de la liste existante (maintenue par le logiciel)
.programme). Une liste de tableaux) pour comparer, s'il y a la même, on ferme cette fenêtre. Évidemment, cette méthode présente de nombreux défauts. Elle bloque toutes les fenêtres pop-up et est trop stricte. Elle est rarement utilisée dans le programme. Cependant, la méthode de déformation qui en découle est assez courante. Autrement dit, la technologie de filtrage intelligent basée sur le nom du titre de la fenêtre bloque les fenêtres contextuelles selon que le titre contient ou non des mots-clés liés à la publicité. Il s'agit d'une bonne exploration pour améliorer l'effet de filtrage.
(2) Méthode de blocage basée sur la classe et l'emplacement de la fenêtre.
Après analyse, il a été constaté que les noms de classe des fenêtres de navigation normales sont IEFRAME et CabinetWClass, tandis que le nom de classe des fenêtres publicitaires est CabinetWClass. Une analyse plus approfondie a révélé que : les valeurs de rect.top de la classe WorkerA de la fenêtre publicitaire et de la classe Shell DocObject View sont les mêmes, mais les valeurs de rect.top de la classe WorkerA de la fenêtre IE normale et la classe Shell DocObject View est différente. Sur la base des deux points ci-dessus, vous pouvez écrire un programme anti-publicité. En fait, je suis sceptique quant à la généralisabilité de ce programme. Parce que l'auteur a utilisé Spy++ pour analyser et a découvert que dans Windows2000 (le système d'exploitation utilisé par l'auteur), les classes des fenêtres IE sont toutes des IEFrame. Parallèlement, Win2000 étant un système d'exploitation basé sur du code Unicode, il n'existe pas de classe WorkerA et est remplacée par la classe WorkerW. En même temps, il n'y a aucune situation où rect.top est différent Étant donné que l'auteur n'a pas de système d'exploitation WindowsXP, je ne peux pas mener d'autres expériences sur WindowsXP.
(3) Méthodes de blocage basées sur les composants IE COM
Les deux méthodes ci-dessus traitent la fenêtre IE comme une fenêtre Windows ordinaire et émettent des jugements. En fait, IE est un navigateur typique basé sur des composants COM. Tous les navigateurs basés sur le noyau IE emballent le fichier shdocvw.dll, puis écrivent le code BHO correspondant. Ce n'est qu'ainsi que nous pourrons véritablement contrôler le navigateur IE, au lieu d'effleurer la surface comme les méthodes un et deux.
Il existe également une méthode de blocage des fenêtres contextuelles basée sur le noyau IE. Il bloque les pop-ups avant leur ouverture. Le principe est le suivant : chaque fois qu'IE ouvre une nouvelle fenêtre, l'événement NewWindow sera déclenché et la méthode OnNewWindow2([out] IDispatch*, [out] BOOL *bCancel) sera exécutée. Surchargez cette méthode pour déterminer si l'événement d'ouverture d'une nouvelle fenêtre se produit après le téléchargement de la page de navigation. Si c'est le cas, cela signifie qu'il s'agit d'une fenêtre pop-up normale, sinon elle sera interceptée.
Étant donné que les navigateurs comme Gosurf surchargent le composant Shocvm.dll, il est naturel d'utiliser la troisième méthode. Cependant, lors de l’utilisation, on constate parfois que le filtrage des publicités n’est pas parfait, mais le principe est fondamentalement le même.