Links

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:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Dummy.aspx.cs" Inherits="DesignerExample.Dummy" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<form id="form1" runat="server">
<div>
<asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />
</div>
<div>
<asp:DropDownList ID="DropDownList1" runat="server" Height="12"></asp:DropDownList>
</div>
</form>
</body>
</html>

.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
namespace DesignerExample
{
public partial class Dummy : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void Button1_Click(object sender, EventArgs e)
{
}
}
}

.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:
namespace DesignerExample
{
public partial class Dummy
{
protected global::System.Web.UI.HtmlControls.HtmlForm form1;
protected global::System.Web.UI.WebControls.Button Button1;
protected global::System.Web.UI.WebControls.DropDownList DropDownList1;
}
}

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 binded events of all the controls declared at the .aspx class).
Here is a converted example of how a converted aspx.cs class looks like:
namespace DesignerExample
{
[Observable]
public partial class Dummy : Mobilize.Web.UI.Controls.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void Button1_Click(object sender, EventArgs e)
{
}
}
}

.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:
namespace DesignerExample
{
public partial class Dummy
{
public Dummy()
{
this.InitializeComponent();
}
[Intercepted]
protected Mobilize.Web.UI.Controls.HtmlControls.HtmlForm form1 { get; set; }
[Intercepted]
protected Mobilize.Web.UI.Controls.Button Button1 { get; set; }
[Intercepted]
protected Mobilize.Web.UI.Controls.DropDownList DropDownList1 { get; set; }
private void InitializeComponent()
{
this.Name = "Dummy";
this.form1 = new Mobilize.Web.UI.Controls.HtmlControls.HtmlForm();
this.Button1 = new Mobilize.Web.UI.Controls.Button();
this.DropDownList1 = new Mobilize.Web.UI.Controls.DropDownList();
this.form1.Name = "form1";
this.Button1.Name = "Button1";
this.Button1.Text = "Button";
this.Button1.Click += new System.EventHandler(this.Button1_Click);
this.DropDownList1.Name = "DropDownList1";
this.DropDownList1.Height = new Mobilize.Web.UI.Controls.Unit("12");
this.Controls.Add(this.form1);
this.Controls.Add(this.Button1);
this.Controls.Add(this.DropDownList1);
}
}
}
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:
  1. 1.
    GridView
  2. 2.
    DataList
  3. 3.
    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.
<asp:GridView ID="gridView" runat="server" AutoGenerateColumns="false" PageSize="10"
GridLines="Vertical" CssClass="Grid" Width="40%" AllowPaging="true"
ShowHeader="true">
<Columns>
<asp:BoundField DataField="Name" HeaderText="BoundField"/>
<asp:TemplateField HeaderText="LabelField" ItemStyle-Width="50%">
<ItemTemplate>
<asp:Label runat="server" Text='<%# Bind("Name") %>'
ID="lblID"></asp:Label>
</ItemTemplate>
</asp:TemplateField>
</Columns>
</asp:GridView>
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.
private void InitializeComponent() // This method is declared in the aspx.designer.cs file
{
this.Name = "Dummy";
this.form1 = new Mobilize.Web.UI.Controls.HtmlControls.HtmlForm();
this.gridView.Name = "gridView";
this.gridView.AutoGenerateColumns = false;
this.gridView.PageSize = 10;
this.gridView.GridLines = Mobilize.Web.UI.Controls.GridLines.Vertical;
this.gridView.CssClass = "Grid";
this.gridView.Width = new Mobilize.Web.UI.Controls.Unit("40%");
this.gridView.AllowPaging = true;
this.___Build__GridColumns0(this.gridView.Columns);
this.Controls.Add(this.form1);
this.Controls.Add(this.gridView);
}
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 like shown in the following code.
private void ___Build__GridColumns0(Mobilize.Web.UI.Controls.DataControlFieldCollection lst__cntrl)
{
lst__cntrl.Add(this.___Build__Control1());
lst__cntrl.Add(this.___Build__Control2());
}
In this case the first .Add of the collection of the __Build_Control1 method is a BoundField, this .Add allows to create a new instance of such control, setting the property information (That were 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.
private Mobilize.Web.UI.Controls.BoundField ___Build__Control1()
{
Mobilize.Web.UI.Controls.BoundField BoundField = new
Mobilize.Web.UI.Controls.BoundField();
BoundField.DataField = "Name";
BoundField.HeaderText = "BoundField";
return BoundField;
}
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).
private Mobilize.Web.UI.Controls.TemplateField ___Build__Control2()
{
Mobilize.Web.UI.Controls.TemplateField TemplateField =
new Mobilize.Web.UI.Controls.TemplateField();
TemplateField.HeaderText = "LabelField";
TemplateField.ItemStyle.Width = new Mobilize.Web.UI.Controls.Unit("50%");
TemplateField.ItemTemplate = new Mobilize.Web.UI.CompiledBindableTemplateBuilder(
new Mobilize.Web.UI.BuildTemplateMethod(this.___Template__Control3), null);
return TemplateField;
}
This __Template_Control3 methods fills the controls list of an TemplateField.ItemTemplate.
private void ___Template__Control3(Mobilize.Web.UI.Controls.Control __cntrl)
{
__cntrl.Controls.Add(this.___Build__Control4());
}
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.
private Mobilize.Web.UI.Controls.Label ___Build__Control4()
{
Mobilize.Web.UI.Controls.Label Label = new Mobilize.Web.UI.Controls.Label();
Label.DataBinding += new System.EventHandler(this.___DataBinding___control5);
Label.Name = "lblID";
return Label;
}
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 binded property with the Eval method.
private void ___DataBinding___control5(object sender, System.EventArgs e)
{
Mobilize.Web.UI.Controls.Label Label = (Mobilize.Web.UI.Controls.Label)sender;
Mobilize.Web.UI.IDataItemContainer Container = (Mobilize.Web.UI.IDataItemContainer)
Label.BindingContainer;
if ( this.Page.GetDataItem() == null )
return ;
Label.Text = System.Convert.ToString(this.Eval("Name"));
}

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.
<asp:DataList ID="datalist" runat="server">
<ItemTemplate>
<table>
<tr>
<td>
<asp:Label ID="lbl1" runat="server" Text="Label text"></asp:Label>
<br />
<asp:TextBox ID="txt1" MaxLength="100" runat="server"
Text='<%# Bind("Name") %>'></asp:TextBox>
</td>
</tr>
</table>
</ItemTemplate>
</asp:DataList>
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 adding 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.
private void InitializeComponent() // This method is declared in the aspx.designer.cs file
{
this.Name = "Dummy";
this.datalist = new Mobilize.Web.UI.Controls.DataList();
this.datalist.Name = "datalist";
datalist.ItemTemplate = new Mobilize.Web.UI.CompiledBindableTemplateBuilder(new
Mobilize.Web.UI.BuildTemplateMethod(this.____Build_Control0), null);
this.Controls.Add(this.datalist);
}
private void ____Build_Control0(Mobilize.Web.UI.Controls.Control cntrl)
{
cntrl.Controls.Add(this.___Build__Control1());
cntrl.Controls.Add(this.___Build__Control2());
}
private Mobilize.Web.UI.Controls.Label ___Build__Control1()
{
Mobilize.Web.UI.Controls.Label Label = new Mobilize.Web.UI.Controls.Label();
Label.Name = "lbl1";
Label.Text = "Label text";
return Label;
}
private Mobilize.Web.UI.Controls.TextBox ___Build__Control2()
{
Mobilize.Web.UI.Controls.TextBox TextBox = new Mobilize.Web.UI.Controls.TextBox();
TextBox.Name = "txt1";
TextBox.MaxLength = 100;
TextBox.DataBinding += new System.EventHandler(this.___DataBinding___control3);
return TextBox;
}
private void ___DataBinding___control3(object sender, System.EventArgs e)
{
Mobilize.Web.UI.Controls.TextBox TextBox = (Mobilize.Web.UI.Controls.TextBox)sender;
Mobilize.Web.UI.IDataItemContainer Container = (Mobilize.Web.UI.IDataItemContainer)
TextBox.BindingContainer;
if ( this.Page.GetDataItem() == null )
return ;
TextBox.Text = System.Convert.ToString(this.Eval("Name"));
}

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.
<asp:DropDownList ID="DropDownList1" runat="server" Width="100px">
<asp:ListItem Value="Yes" Text="Yes"></asp:ListItem>
</asp:DropDownList>
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.
private void InitializeComponent() // This method is declared in the aspx.designer.cs file
{
this.Name = "Dummy";
this.DropDownList1 = new Mobilize.Web.UI.Controls.DropDownList();
this.DropDownList1.Name = "ddlIsPublicDomain";
this.___Build___Items0(this.DropDownList1.Items);
this.Controls.Add(this.DropDownList1);
}
private void ___Build___Items0(Mobilize.Web.UI.Controls.ListItemCollection ___lst)
{
___lst.Add(this.___Build__Control1());
}
private Mobilize.Web.UI.Controls.ListItem ___Build__Control1()
{
Mobilize.Web.UI.Controls.ListItem ListItem = new Mobilize.Web.UI.Controls.ListItem();
ListItem.Value = "Yes";
ListItem.Text = "Yes";
return ListItem;
}