Auteur : Dflying Chen ( http://dflying.cnblogs.com/ )
PS : Grâce à l'amour de tous, j'ai beaucoup appris pendant les deux mois où je me suis installé dans le parc des blogs, je me suis fait de nombreux amis et j'ai reçu de nombreuses opportunités. Actuellement, j'ai l'honneur de traduire un livre d'Atlas : Foundations of Atlas: Rapid Ajax Development with ASP.NET 2.0, qui devrait être publié par la People's Posts and Telecommunications Publishing House dans trois mois. Par conséquent, j'ai été très occupé pendant cette période et le blog ne peut pas être mis à jour aussi fréquemment qu'il y a quelque temps, je m'en excuse. Bien sûr, les amis sont invités à continuer à discuter des questions liées à Atlas, et je ferai de mon mieux pour y répondre.
Au cours des deux prochains mois, j'espère viser l'excellence dans la traduction des Fondements d'Atlas, il y aura donc certainement de nombreuses questions qui devront être discutées avec des amis, comme la terminologie, le style de traduction, etc. Merci d'avance ici!
Dans l'article précédent (veuillez vous référer à : Développement du contrôle d'extension côté serveur ASP.NET Atlas - écriture du comportement côté client), nous avons déjà écrit le comportement côté client. Dans cet article, terminons-le et exécutons-le en tant que contrôle côté serveur.
Venons-en d’abord au fichier ValidateUserNameProperties.cs. Cette classe hérite de la classe de base TargetControlPropertiesBase<Control>, qui définit la relation de mappage entre les valeurs des propriétés client et les valeurs des propriétés du serveur. Dans le même temps, la classe de base TargetControlPropertiesBase<Control> et Atlas Control Extender ont déjà effectué le travail de génération d'un script XML côté client pour vous. Il vous suffit de définir les attributs requis par votre comportement.
Cinq attributs, CheckResultLabelID, ServiceName, MethodName, ValidMessage et InvalidMessage, doivent être ajoutés. Par souci de simplicité, je donne seulement un exemple d'attribut
[DefaultValue("")]
[IDReferenceProperty(typeof(WebControl))]
[Propriété requise()]
chaîne publique CheckResultLabelID
{
obtenir
{
return GetPropertyStringValue("CheckResultLabelID");
}
ensemble
{
SetPropertyStringValue("CheckResultLabelID", valeur);
}
}
La définition de CheckResultLabelID est précédée de trois attributs :
DefaultValue : définissez la valeur par défaut de cet attribut.
IDReferenceProperty : spécifie que cette propriété peut uniquement stocker l'ID d'un type de contrôle spécifique.
RequiredProperty : Spécifie que cette propriété est obligatoire.
Pour plusieurs autres propriétés, vous pouvez vous référer aux fichiers sources fournis ultérieurement.
Jetez ensuite un œil au fichier ValidateUserNameExtender.cs. Les parties principales sont les suivantes :
[Designer(typeof(ValidateUserNameDesigner))]
[ClientScriptResource("Dflying", "ValidateUserNameBehavior", "Dflying.Atlas.ControlTookit.ValidateUserName.ValidateUserNameBehavior.js")]
[RequiredScript (type de (ValidateUserNameExtender))]
classe publique ValidateUserNameExtender : ExtenderControlBase<ValidateUserNameProperties, Control>
{
}
Parmi eux, notre ValidateUserNameExtender hérite de la classe de base ExtenderControlBase<ValidateUserNameProperties, Control> et obtient certaines opérations courantes. Et trois attributs sont appliqués à la classe :
Concepteur : spécifiez le nom de classe du concepteur de cet Extender (utilisé pour fournir une prise en charge au moment du design).
ClientScriptResource : Spécifie les informations requises pour générer les scripts XML Atlas clients. Les valeurs Dflying et ValidateUserNameBehavior doivent ici être cohérentes avec celles définies dans le précédent ValidateUserNameBehavior.js.
RequiredScript : spécifiez le script requis par le client, afin qu'Atlas lie ValidateUserNameBehavior.js à la page sous la forme d'un fichier axd.
Enfin, il existe le fichier ValidateUserNameDesigner.cs, dans lequel vous pouvez ajouter la prise en charge au moment du design. Laissez votre contrôle avoir différents styles d'affichage avec différentes valeurs de propriété définies dans Visual Studio. Pour simplifier ici, je n'ajouterai pas de support au moment du design.
À ce stade, notre Extender a été écrit et la DLL générée après une Release Build peut être utilisée directement. Dans le prochain article, je démontrerai l'utilisation de cet Extender dans un programme réel.