Designer classes on WebForms Conversion Tool
This documentation has the purpose of explaining to any WebMap user how the ConversionTool generates the .designer class and any other extra classes needed classes for the correct functionality of WebForms architecture when converted.
First, we will discuss how WebForms resolves the pages, also, it will have a section with the solution provided for this architecture.
How the legacy WebForms technology separates the classes
There are three main components that represent our page:
.aspx class
This is the main class where we declare the html code, declarative server control markup and JavaScript code (If needed).
Here is an example of how the .aspx class looks like:
.aspx.cs class
This is the class where all the UI logic and internal methods are implemented for our page. This file is better known as the “Code-Behind” file. Also, here the corresponding field declarations are added to this file, due to a convention they need to match the name and type of controls defined within the .aspx file.
Here is an example of how a aspx.cs class looks like
.aspx.designer.cs class
The main purpose of this class is to serve as a bridge between the last 2 classes discussed previously, here we declare all the controls contained in the page, if is not declared the project will prompt and error (The "X" control does not exist in the current context). The linkage of this classes is done based on the “Inherits” property on the .aspx together with the namespace and class of the .aspx.cs CodeBehind file. The final segment of the “Inherits” property must be the same as both the class name of the .aspx.designer.cs and the CodeBehind tag to be able to solve it. This class is autogenerated and only exists when we create a Web Application Project.
Here is an example of how a designer class looks like:
How is it separated when we convert an application to WebMap technology?
When we convert the application, it will have the following separation:
.aspx.cs
This file remains the same as in the original application preserving the logic of the page (Methods and bound events of all the controls declared at the .aspx class).
Here is a converted example of how a converted aspx.cs class looks like:
.aspx.designer.cs
Compared to the legacy file, when it is converted this class will include a new method called “InitializeComponent” in the constructor of the class and it has declared the properties and events of all the controls at the original HTML file to be filled with their respective data. Furthermore, the initialized data in this section is moved and generated from the original HTML.
Here is a converted example of how a converted designer class looks like:
Note: At the very end of each InitializeComponent we will add all those controls to our page.controls list (this.Controls.Add(this.form1);) to keep all information up to date.
.aspx.__mobilize.cs
This class exists because of several controls such as the GridView, DataList and DropDownList will have a list of new controls defined inside of them which are automatically generated by the .NET assemblies (*.dlls files), so there was the need to create a new implementation for this functionality when the app was converted to support controls of controls (These controls are defined by templates and can contain also binding events and styles which are added in this new generated code to fully convert their functionality). Here it is going to be contained a set of methods in charge of filling the properties of such inner controls, being declared depending on the type of control list we have available at the main control (Those generated methods are enumerated from 0 to n) This class will not be generated unless we have one of the following cases:
GridView
DataList
DropDownList
Case 1: GridView control
This GridView case will only prompt the class if the AutoGenerateColumns property is set to false and a set of the following DataControlFields defined in the .aspx class
BoundField
CommandField
HyperLinkField
TemplatedField
Here is a small example of how a GridView with those characteristics looks like.
Those controls are defined in the Columns tag and will prompt a new line of code in the InitializeComponent method with this syntax in bold.
Now, the GridView takes two different approaches when the methods are being generated:
The first case is when the GridView has declared a TemplateField. This TemplateField can contain an ItemTemplate that allows the control to define Data-Binding expressions, and this has a different structure generated at the assembles .dlls files.
The second case is possible only if the GridView has declared a DataBoundField, HyperLinkField or a Command field, they also can contain Data-Binding expressions, but does not support the ItemTemplate property, this code generation is much simplistic besides the first case.
These structures are represented in the following image:
Once the separation is clear we can continue with the code generation at the __mobilize.cs class. Now, the .Columns property sent at the __Build_GridColumns0 method is a data structure of type DataControlFieldCollection in which we add the set of controls needed for each item inside the collection as shown in the following code.
In this case the first .Add of the collection of the __Build_Control1 method is a BoundField, this .Add allows to creating a new instance of such control, setting the property information (That was declared in the original *.aspx class) their respective values and returning this instance to be added to the DataControlFieldCollection of our GridView. This applies also to the HyperLinkField and CommandField controls.
Now, diving into the TemplateField case and the ItemTemplate it contains, the __Build_Control2 method is the same as the one we have above, however, when a TemplateField is declared inside the Column’s HTML tag of a GridView it allows to declare other controls besides the predefined by DataControlFields. This means that the GridView Columns is a collection of DataControlFields and if one of those is a TemplateField it will contain a ItemTemplate property which is a new collection of controls and has the possibility to declare bindable properties in them. This item template will be updated with the CompiledBindableTemplateBuilder and it is used to parse two-way data-binding expression coming from a DataSource (Could be a database or an embedded resource declared in the project).
This __Template_Control3 method fills the controls list of a TemplateField.ItemTemplate.
Those controls are built inside the __Build__Control4 method. When we have a DataBinding property inside the control that is being created it is going to be assigned at the Event and filled inside the __DataBinding_control5.
Once inside the event, it generates the Control.BindingContainer (The reference to the Control object that contains the data-binding information for the current control) and then sets the bound property with the Eval method.
Case 2: DataList control
The DataList case will generate the __mobilize.cs class if it has a given Control declared inside the DataList at the .aspx. As well as the GridView it has the same differentiation where it can contain several ItemTemplates, controls and controls with data-bindable properties. This ItemTemplate specifies the Items present in the DataSource and it renders itself in the browser and displays as many rows present in the data source collection of the DataList.
Here is an example of how the DataList looks like in the .aspx class.
And here is an image that represents the code above.
Besides this structure, it maintains the same method generation as the GridView, allowing us to fill its inner controls properties and add them to the page controls list at the very end of the Initialize controller method. Here is an example of the code generated by the DataList presented before.
Case 3: DropDownList control#
The DropDownList case will be like the GridView case as well as the DataList’s but this one does not contain an ItemTemplate with different inner controls, however, it has the same structure of methods in charge of filling the properties of the ListItems defined at the DropDownList. The _mobilize.cs class will only be generated when the control has <asp:ListItem> defined in the original application.
Here is an image representing the code we have above.
Once we start converting the app it will generate the __Build_Items0 (this.dllIs PublicDomain.Items) method so we can assign and fill all the properties of the ListItems.
Last updated
Was this helpful?
