Welcome in the second and half post in the series dedicated adventures with Atlas Extenders. Originally, this series consist of three parts, but some changes in the world forces me to add one more post into the series:
- Introduction – what Atlas Extender is and how to create our own validation extender,
- Page methods – how to add AJAX server-side validation,
- Migration – from Atlas to ASP.NET 2.0 AJAX,
- Integration with page – how to integrate extender with ASP.NET page to perform full form validation.
Last time I was blogging about new release of the Atlas. Honestly, I was the very first with that news, but none noticed that. What a pity. Anyway, I promised to write a bit more about changes and because I'm working on extender it is good opportunity to see how these changes are working in real life.
First of all, as I've mention before, several fundamental changes were made in the extender structure. Instead of four source files (Behavior.js, Designer.cs, Extender.cs and Property.cs) only three left. All properties have been relocated into the base Extender class. That's mean that we can't use multiple properties for the extender anymore, as it was in previous version, but we have to add separate extenders for every control we want to extend. It is not a big deal but a little waste of screen space.
Ok, the migration. After removing old references and namespace declarations as well, and after adding new ones, we can start converting existing extender.
Firstly, in the ValidatorExtender.cs, the class declaration should be changed for inherited from the ExtenderControlBase, as generic version of this base class does not exist anymore. Then all properties from the ValidatorProperties.cs should be copied to the Extender class and each of them should be followed by the ExtenderControlProperty attribute. Old Propertises.cs can be removed from the project now. Finally, the TargetControlType attribute should be added just before the Extender class to define type of target control. This allows us to limit extender to selected control type only.
Next step is a quick change in the ValidatorDesigner.cs, where the Designer class declaration should be modified to
class ValidatorDesigner : ExtenderControlBaseDesigner<ValidatorExtender>
{
}
Finally, we should change the ValidatorBahavior.js file where is a lot of important changes. The new Behavior.js consists of two parts, Validator.ValidatorBehavior object and prototype Validator.ValidatorBehavior.prototype. Because our old Behavior.js consists of only one part, we have to split our code. All property declarations should stay in main object whereas rest should go into prototype.
After splitting copying and reformatting the code, we have to ensure if we are using "this." in every field declaration and everywhere we are using them later. The getDescriptor() function is no longer required so should be removed. Because object doesn't contain this.control property anymore, rename all its occurrences of from "this.control.elements" to "this.get_element()". Then, everywhere we are using $(name) it should be changed to $get(name) and finally, last two lines should be replaced as follows:
//before
Validator.ValidatorBehavior.registerSealedClass('Validator.ValidatorBehavior', Microsoft.AtlasControlExtender.BehaviorBase);
Sys.TypeDescriptor.addType('Validator'.toLowerCase() /* Safari Compat */, 'ValidatorBehavior', Validator.ValidatorBehavior);
//after
Validator.ValidatorBehavior.registerClass('Validator.ValidatorBehavior', AjaxControlToolkit.BehaviorBase);
After completing this boring part, we can start refactoring more important things around calling the WebMethod. In the first shot, _onMethodAborted function should be removed and then, arguments in all three functions left should be changed to (sender, eventArgs). To get user context we need now to use sender.get_userContext() and sender.get_result() in _onMethodComplete to get result.
Last thing to do is changing the way, how the WebMethod is invoked. Because this part of framework has been completely changed, we can't use Sys.Net.PageMethod.invoke() anymore. Instead of that, we have Sys.Net.ServiceMethodRequest class that will do exactly the same, so the WebMethod call will now looks as follow:
var svr = new Sys.Net.ServiceMethodRequest();
svr.set_methodName(this._serviceMethod);
svr.get_parameters()["Value"] = args.Value;
svr.get_parameters()["IsValid"] = args.IsValid;
svr.add_completed(Function.createDelegate(this, this._onMethodComplete));
svr.add_error(Function.createDelegate(this, this._onMethodError));
svr.add_timeout(Function.createDelegate(this, this._onMethodTimeout));
svr.invoke(this._currentCallID);
Well, that class does the same but not exactly. I've found unexpected problems with calling the WebMethod. I've found somewhere (can't find it again) information that there is an issue in framework that allows to call WebMethods only when is located in script block in aspx page. Hope this will be corrected soon.
Process of the migration of the web application itself is well described in guide, provided on ASP.NET 2.0 AJAX webpage so that's all for now. After tests everything is working well and I can focus again on finishing extender, so the next, final part will be ready soon.