Desktop Compatibility Platform (DCP)

This section talks about the Desktop Compatibility Platform commonly called DCP. It is a set of bundle packages composed of two main libraries Mobilize.Web.PB.BundleBasic and Mobilize.Web.PB.BundleBasic.DTO which are used to handle:

GUI life-cycles
Back-end controls: a class that holds state and operations to provide compatibility with the PowerBuilder objects, these objects are also known as Models.
Data Transfer Objects (DTO): is a plain old c# object. This class does not have any methods and it used only to send information back and forth with the front-end layer.
Mappers for the DTO: is a class that takes a control model and maps it to a data transfer object and vice versa.
Modal Dialog and Modal Messages.
Application State.
Command/Event execution.
Type Resolution: mechanism used by WebMAP to solve types between libraries.
Wrappers: a wrapper is a class used to hold the state of an object that cannot be migrated directly by the Conversion Tool or that are part of a third party library. For the PowerBuilder migration these classes are often used to handle the System.Collections library. E.g. The System.Collections.Generic.List will have to get a wrapper for this class in order to maintain this structure in the session.
Controllers: is a Web API Controller class that will enable the data query requests. Controls such as the DataManager, Treeview, ListBox, etc, need to use an APi to fetch their data from the back-end to the front-end in separate structure from their models.

The DCP is the most important component for the migrated code in the back-end application, it is the one that provides the functionality equivalent to the original source platform and its components. It also the component that determines what and how the back-end control will be sent to front-end and what deltas (DTO) coming from the front-end will be synchronized with the back-end control.

Bundles

Bundle Basic

The BundleBasic library is the one that provides the Control Models, GUI Life cycle mechanism, Application State mechanism, among others that are vital to emulate the original PowerBuilder behavior in the back-end of the migrated code.

Models

A model is a C# class used to represent the data of a PowerBuilder component, for each PowerBuilder control there is an equivalent model in WebMAP. E.g. Window Control in PB has a Window.cs model in WebMAP, a StaticText has its equivalent StaticText.cs model as well.

The state of each model needs to be tracked down by the WebMAP.CoreServices so it can adequately handle its reference count and ensure the object gets persisted in the application's current session. In order to do so the Observable and Intercepted attributes are used to mark model's classes and properties respectively.

Observable attribute: used to mark a model class as Observable; this means that this class contains properties that need to be tracked down by the WebMAP.CoreServices mechanism.
Intercepted attribute: is used to mark a property as observable, this means that the WebMAP.CoreServices will keep reference tracking of this object so it won't get removed by .NET framework during the garbage collection process. The interception mechanism is used by the Mapper mechanism as well, to ensure the property deltas are sent to the front-end only when they were modified, if a non intercepted property is used in a mapper it will send its value to the front-end in every single request made. The use of intercepted properties has the following restrictions.
- The attribute to be needs applied individually to each auto-property in an observable class. Properties that are not auto-properties (the get or set have any kind of implementation in them) cannot be marked as intercepted.
- In order to work correctly the Intercepted attribute has to be used in a class that is also has the Observable attribute, otherwise it won't work.
- The type of the property needs to be a value type (int, long, string, bool, etc), another observable class or an object that has registered an Observable Wrapper or the WebMAP.CoreServices won't be able to keep track of it.

    [Mobilize.WebMap.Common.Attributes.Observable]
    public class Window : Control, IWindow
    {
        [Mobilize.WebMap.Common.Attributes.Intercepted]
        public bool? Visible { get; set; }
    }

Type Resolution

In a Powerbuilder is common to have circular references between libraries (which are resolved automatically), however, for the default .NET's project dependency this is not valid, and it cannot be used for the migrated solutions.

To solve this problem, type resolution was a mechanism created. PowerBuilder's instancing process is handled by the create method, which takes a type a parameter and returns and instance of the same type. WebMAP uses a similar concept except that instead of using the direct type; an interface is used. As shown in the image and code snippet below.

    var myApplication = Mobilize.Web.Application.Create();

In the migrated code for each class in the PowerBuilder code an interface is generated as well. Because the libraries cannot referenced between them they are then registered in the Application Site and the Create method is the one who decides how the instances are created.

In the Application Site AssemblyInfo class all of the libraries are registered in the same order as they were in the original application. This is important because if there is an interface with the same name in both Library1 and Library4, the one in Library1 is the one that gets instantiated because is the first one in the registration catalog.

    // ApplicationSite AssemblyInfo.cs
    [assembly: AssemblyLoadOrder(typeof(MyApplication.AssemblyIdentifier))]
    [assembly: AssemblyLoadOrder(typeof(Library1.AssemblyIdentifier))]
    [assembly: AssemblyLoadOrder(typeof(Library3.AssemblyIdentifier))]
    [assembly: AssemblyLoadOrder(typeof(Library4.AssemblyIdentifier))]
    [assembly: AssemblyLoadOrder(typeof(Library2.AssemblyIdentifier))]

BundleBasic.DTO

This project holds all of the necessary mechanisms used to communicate between the back-end the front-end applications.

Data Transfer Objects (DTO)

A Data Transfer Object is a plain C# object. This class does not have any kind methods and it is used only to send information back and forth between the back-end the front-end. A DTO serves as a contract between the server and the client layers, if a model property needs to be sent to the front-end it has to necessarily be included in the DTO specification.

    public class SingleLineEdit : IDataTransfer
    {
        public string Text { get; set; }
        public string Id { get; set; }
        public string MapperId { get; set; }

    [DataTransfer("dwColumn")]
    public class DmColumn
    {
        public Alignment? Alignment { get; set; }
    }

A DTO either has to be marked with the DataTransfer or has to implement the IDataTransfer which one depends mostly on the Mapper registration system.

Mappers

A Mapper is a class that takes a control and maps it to a data transfer object and vice versa. In other words, it glues up the Models and the DTO. When we want to send something to client or we want to synchronize deltas sent by client with back-end controls, we'll both require the mapper.

In order to create mapper it needs to implement the IMapper interface, been TModel and TDTO its respective Model and DTO types associated.

    public class SingleLineEditMapper : IMapper
    {
    }

It also need to be registered directly as a Mapper or as a part of a Mapper factory. A mapper can only be registered for a specific Type which means that if there is a class that inherits from a control that already has a mapper registered it won't work for the child class, to accomplish this a MapperFactory needs to be used.

    catalog.AddMapper(new DmColumn());

A MapperFactory is basically an object that allows a single mapper to be used by several types at the same time, this is commonly implemented for inherited classes.

    catalog.AddMapperFactory(new SingleLineEditFactory());

    public class SingleLineEditFactory : IMapperFactory
    {
        public bool CanGetMapper(Type type)
        {
            return typeof(Web.SingleLineEdit).IsAssignableFrom(type);
        }

        public MapperInformation GetMapperInformation(Type type)
        {
            return new MapperInformation(
                id: NamingConventions.ToClientName(type.FullName),
                mapper: new SingleLineEditMapper(type),
                inType: type,
                outType: typeof(DTO.SingleLineEdit));
        }
    }

Wrappers

An observable wrapper is a class that wraps another class that cannot be tracked via WebMAP's observable mechanism, they are commonly implemented for objects such as .NET native classes and data structures.

API/Controllers

Used to send data between back-end and front-end. Commonly used to send bulk data that is too big to be sent via DTO.

Controllers are responsible for responding to requests made from the front-end. In WebMAP, the items or nodes of a DataManager, DropDownListBox, ListBox and Treeview are not sent within the standard WebMAP request, so these kind of items and nodes are sent by means of a Controller Action.

    [Route("api/treeview/FetchItems")]
    [ApiController]
    public class TreeViewController
    {
        [HttpGet("{id}")]
        public Dictionary GetTreeViewItem(WebTreeView tv)
        {
            //...
        }
    }

PreviousConversion Tool NextData Manager