Microsoft Dynamics Ax 2009 : Programming Enterprise Portal Controls (part 4) - ViewState, Page Life Cycle, Proxy Classes

ViewState

The Web is stateless, which means that each request for a page is treated as a new request, and no information is shared. When loaded, each ASP.NET page goes through a regular page life cycle, from initialization and page load onward. When a user interacts with the page, causing the need for the server to process some control events, ASP.NET posts the values of the form to the same page for processing the event on the server. A new instance of the Web page class is created each time the page is requested from the server. When postback happens, ASP.NET uses the ViewState feature to preserve the state of the page and controls so that any changes made to the page during the round-trip are not lost. The Enterprise Portal framework leverages this feature, and Enterprise Portal ASP.NET controls automatically save their state to ViewState. The ASP.NET page reads the view state and reinstates the page and control state in its regular page life cycle. So you don’t need to write any code to manage the state if you’re using Enterprise Portal controls. But if you want to persist any values in memory variables, you can write code to add or remove items from StateBag in ASP.NET. If you need to save the state of an X++ data set, you can use the pack and unpack design pattern to store the state, as shown here.

public int Counter
{
    get
     {
        Object counterObject = ViewState["Counter"];
        if (counterObject == null)
        {
            return 0;
        }
       return (int)counterObject;
     }
    set
     {
        ViewState["Counter"] = value;
    }
}

The Enterprise Portal framework uses the EPStateStore table in Dynamics AX to store the state of AxDataSourceControl. The states of all other controls are stored in the ASP.NET view state for added security. This storage is per user, and each user can read only his or her information. Writes and deletes are protected with AOS methods, and read is protected via code access permission.

Page Life Cycle

When an Enterprise Portal page runs, it goes through a life cycle in which it performs a series of steps and raises events at various states so developers can write code to control the behavior of the page and its controls, create dynamic controls, and write user interface logic. Understanding the sequence of the page processing and events helps you write the user interface logic at the appropriate level.

Proxy Classes

If you need to call X++ classes or table methods or enums in your Web User Control, the Enterprise Portal framework provides an easy way of creating managed wrappers for these X++ objects and using them in your Web User Control. A proxy file internally wraps the .NET Business Connector calls and provides a simple, easy-to-use, typed interface for C# applications. The proxies file under Web\Web Files\Static Files in the AOT contains information about all the X++ objects for which a proxy file needs to be generated. The proxy generation tool uses this file when the Enterprise Portal site is deployed. The proxy files are automatically created and deployed to the App_Code folder of the IIS Web site. Table 1 describes the various command line options for the proxy generator.

For example, to generate a proxy file for the SampleProxy class, add the following code to the Web\Web Files\Static Files\Proxies node in the AOT.

warn:2 /references+ /methods- /namespace:Microsoft.Dynamics.Portal.Application.Proxy

/class:SampleProxy
  /method:SampleProxy.sampleProxiesNoParameters
  /method:SampleProxy.sampleProxiesStaticMethod

					  

The first line of the preceding code provides the generation options for the proxy file. The second line provides information about the X++ class for which the proxy file needs to be generated. When Enterprise Portal is deployed, a SampleProxy.cs is created; it contains two methods and is deployed to the App_Code folder of the IIS Web site.

From Visual Studio, you can right-click the App_Code folder in a Dynamics AX Web project and choose the Generate Proxies option. The Visual Studio add-in generates the proxy files defined in the Proxies file and adds them to the Visual Studio project.

To use the proxy from C# code in the Web User Controls, first add a using statement to the proxy namespace, like this.

using Microsoft.Dynamics.Portal.Application.Proxy;

Then you can access these X++ methods as if they were in C#. You can access some items in the proxy, such as enums, directly, without any additional code. Accessing methods from the proxy requires passing the IAxaptaAdapter object together with the method call. So you need to get the session and pass it to the constructor to create the C# proxy object, as shown here.

protected string NoParamProxyCall_Click(object sender, EventArgs e)
    {
        AxBaseWebPart webpart = AxBaseWebPart.GetWebpart(this);
        SampleProxy sampleProxy = null;
        sampleProxy = new SampleProxy(webpart.Session.AxaptaAdapter);
        string s = sampleProxy.sampleProxiesNoParameters();
        return s;
    }