Developing asp.net Atlas server-side extender controls-writing server-side Extender & dflying Recent trends

Asp.net| Server | control

PS: Thank you for your love, in the blog park in the two months I learned a lot of things, met a lot of friends, and got a lot of opportunities. At present, I have the honor to translate an Atlas book: Foundations of Atlas:rapid Ajax Development with asp.net 2.0, estimated three months later in the people's post and Telecommunications press and published. So this time is quite busy, blog can not have a period of time before so frequent updates, hereby apologize. Of course, we welcome friends to continue to discuss the related issues of Atlas and I will try my best to answer them.

In the next two months, I hope to be able to improve the translation of foundations of Atlas, so there must be a lot of questions to discuss with friends, such as terminology, translation style and so on. Here I thank you in advance!

In the previous article (refer to: Develop asp.net Atlas server-side extender control-write client behavior) we have written the behavior of the client. In this article, let's wrap it up and run it as a server-side control.

First comes the ValidateUserNameProperties.cs file, which inherits from the Targetcontrolpropertiesbase<control> base class, The mapping relationship between the client property value and the server-side property value is defined. At the same time, the,targetcontrolpropertiesbase<control> base class and the Atlas control extender have done the job of generating client XML script for you, You just need to define the attributes that your behavior needs.

Checkresultlabelid,servicename,methodname,validmessage and invalidmessage Five attributes should be added. For simplicity, I'll just cite an example of a property

[DefaultValue ("")]
[Idreferenceproperty (typeof (WebControl))]
[Requiredproperty ()]
public string Checkresultlabelid
{
Get
{
Return Getpropertystringvalue ("Checkresultlabelid");
}
Set
{
Setpropertystringvalue ("Checkresultlabelid", value);
}
}

Where the definition of checkresultlabelid is preceded by three attributes:
DefaultValue: Sets the default value for this property.
Idreferenceproperty: Specifies the ID of a particular type of control that can only be stored in this property.
Requiredproperty: It is necessary to specify this attribute.
Several other properties you can refer to the source files that are provided later.

Then look at the ValidateUserNameExtender.cs file, the main part is as follows:

[Designer (typeof (Validateusernamedesigner))]
[Clientscriptresource ("dflying", "Validateusernamebehavior", "" Dflying.Atlas.ControlTookit.ValidateUserName.ValidateUserNameBehavior.js ")]
[Requiredscript (typeof (Validateusernameextender))]
public class Validateusernameextender:extendercontrolbase<validateusernameproperties, control>
{
}

One of our validateusernameextender inherits from Extendercontrolbase<validateusernameproperties, control> the base class, and gets some common operations. and three properties were applied on the class:
Designer: Specifies the class name of the designer for this extender, which is used to provide design-time support.
Clientscriptresource: Specifies the information required to generate the client Atlas XML script. The dflying and Validateusernamebehavior are consistent with what is defined in the previous validateusernamebehavior.js.
Requiredscript: Specifies the script that the client needs, so that Atlas will link the validateusernamebehavior.js to the page in the form of a Axd file.
Finally, the ValidateUserNameDesigner.cs file, where you can add a design-time support program. The display style is different for your control in Visual Studio, depending on the property values you set. For simplicity, I don't add design-time support.

As of this time, our Extender is written, and the DLL generated after a release build can be used directly. In the next article, I'll show you how to apply this extender in a real-world program.