<o:p>
Starting tasks<o:p>
<o:p>
To get the task started there are different ways which depends on the navigation model we used. They have the UserControlNavigation within windows forms. You can now force a user to go in a particular sequence when contained with complex controls within the form. It is not available presently for the web application but may be for the subsequent version they may release it. So in case if you are working with the graphnavigation which is the sequential type of navigation then you need to call StartNavigationTask on UIPManager which has multiple overload.
<o:p>
Implementing Controller<o:p>
<o:p>
You create a custom class which derive from the ControllerBase and number of controller depends on number of tasks you have. This ControllerBase class is available in Microsoft.ApplicationBlocks.UIProcess. Best way is to choose one controller per tasks but in case your application is fairly small, you can have one controller per application. State is maintained on behalf of tasks. Well another thing we do is we implement navigation method which specify which view to demonstrate next based on the contents of Config class. State is accessible in controller as it inherits from ControllerBaseClass and ControllerBaseClass have the property called state through which we can directly access the state.<o:p>
<o:p>
Views<o:p>
<o:p>
Views are derived from their base class: WebFormView or WindowFormView. These base classes are available in Microsoft.ApplicationBlocks.UIProcess It access the state from the controller to initialize itself and to present itself , if necessary take the feeback from the user, modify it and then when you need to navigate to another view, you can save the state back. State is saved in a hash table which is a key value pair. If you need to access strongly type state objects, you can also create your own state. One things that is important is that as soon as we closes the view, we need to store state back. One things is to be kept in mind is that when we need to first change the base class and the layout. Sometimes if we changes the layout and then changes the base class, VS.NET got unhappy and makes some problems in displaying the UI controls. <o:p>
<o:p>
<o:p>
<o:p>
<o:p>
<o:p>
Configuration files <o:p>
<o:p>
Plays a very important role in UIPAB and all sort of configuration information is stored in the configuration file. Its web.config for web applications and <applications>.exe.config for windows applications. <o:p>
<o:p>
If we talk about the configuration files , there have the following schema.<o:p>
<o:p>
<configuration><o:p>
<ConfigSections><o:p>
<section><o:p>
</ ConfigSections><o:p>
<uipConfiguration><o:p>
<objectTypes><o:p>
</objectTypes><o:p>
<views><o:p>
</views><o:p>
<o:p>
<navigationGraph><o:p>
<o:p>
</navigationGraph><o:p>
</uipConfiguration><o:p>
<o:p>
</configuration><o:p>
<o:p>
First of the things is the configSection which tells how application block is plugged into the applications.<o:p>
<o:p>
<configSections><o:p>
<section <o:p>
name="uipConfiguration" <o:p>
type="Microsoft.ApplicationBlocks.UIProcess.UIPConfigHandler, Microsoft.ApplicationBlocks.UIProcess" /><o:p>
</configSections> <o:p>
<o:p>
<o:p>
In this we are specifying that we have .NET UIPAB information will be stored in the uipConfiguration section. We can change it to any other section, if necessary and this section is been handle by a class called uipConfigHandler which resides in Microsoft.ApplicationBlocks.UIProcess namespace. Now UIPConfighandler expect the some standard schema which consist of three elements.<o:p>
<o:p>
- <ObjectTypes><o:p>
- Views<o:p>
- navigationGraph<o:p>
<o:p>
<o:p>
each of these elements also have the sub elements. <o:p>
Now as far as objectTypes is concerned, it contains the type information about various pieces of architecture. So it contains information about viewManager, state , controller and statePersistenceProvider that we should use, <o:p>
<o:p>
<iViewManager <o:p>
name="WinFormViewManager"<o:p>
type="Microsoft.ApplicationBlocks.UIProcess.WinFormViewManager, Microsoft.ApplicationBlocks.UIProcess, Version=1.0.1.0,Culture=neutral,PublicKeyToken=null"/><o:p>
<o:p>
<state <o:p>
name="State1" <o:p>
type="UIProcessQuickstarts_MultiNavGraph.State1, UIProcessQuickstarts_MultiNavGraph, Version=1.0.1.0, Culture=neutral, PublicKeyToken=null"/><o:p>
<o:p>
<controller <o:p>
name="DemoController1" <o:p>
type="UIProcessQuickstarts_MultiNavGraph.DemoController1, UIProcessQuickstarts_MultiNavGraph, Version=1.0.1.0,Culture=neutral,PublicKeyToken=null" /><o:p>
<o:p>
<o:p>
<statePersistenceProvider <o:p>
name="SqlServerPersistState" <o:p>
type="Microsoft.ApplicationBlocks.UIProcess.SqlServerPersistState, Microsoft.ApplicationBlocks.UIProcess, Version=1.0.1.0,Culture=neutral,PublicKeyToken=null"<o:p>
connectionString="Data Source=localhost;Initial Catalog=UIPState;user id=UIP;password=U1Pr0c3ss"/><o:p>
<o:p>
</objectTypes><o:p>
<o:p>
<o:p>
<o:p>
So each sub element of the ObjectTypes have the name and type, where type specify which implementation we are using. For e.g. we are using the IViewManager we will see that we are implementing the winFormViewManager, in case, if we want to make our own base type, we have to specify here. Most of the time we are happy with the default type. So ObjectType identifies the core pieces of architecture and its implementation.<o:p>
<o:p>
<o:p>
After that, it comes the Views elements. <o:p>
<o:p>
<o:p>
<o:p>
<o:p>
<views><o:p>
<view name=”start” type=”start.aspx” controller=”OnlineController” /><o:p>
<view name=”first” type=”first.aspx” controller=”OnlineController” /><o:p>
<view name=”second” type=”second.aspx” controller=”OnlineController” /><o:p>
<o:p>
</views><o:p>
<o:p>
In the view section, we specify all the views that are in the application. Now it contains three attributes. <o:p>
Name attribute specify the name we would refer the view in the controller. So from the actual views, we would call the navigation method of the controller and the controller then refer to view with this logical name and the physical name of the file is specified in the type attribute. Apart from this, we also specify the controller with which this element is expect to work with in the controller attribute.<o:p>
<o:p>
Now comes the navigation graph<o:p>
<o:p>
<navigationGraph<o:p>
name="navA"<o:p>
startView="Form1"<o:p>
state="State1"<o:p>
statePersist="SqlServerPersistState" iViewManager="WinFormViewManager"><o:p>
<node view='Form1'><o:p>
<navigateTo navigateValue="next" view='Form2'/><o:p>
</node><o:p>
<node view='Form2'><o:p>
<navigateTo navigateValue="previous" view='Form1' /><o:p>
<navigateTo navigateValue="next" view="Form3"/><o:p>
</node><o:p>
<node view='Form3'><o:p>
<navigateTo navigateValue="previous" view='Form2' /><o:p>
<navigateTo navigateValue="showPreviousNavState" view='IAmModal' /><o:p>
</node> <o:p>
<o:p>
</navigationGraph><o:p>
<o:p>
<o:p>
Now in navigation graph there are many attributes. Name attribute is used to specify the name of the navigation graph so when we call the StartNavigationGraph then we need to specify this name. so when UIPManager calls the startnavigationGraph method, engine checks the configuration file to check the name and also check which should be the view we should display first which is specified in the startView attribute where we give the logical name of the view, <o:p>
<o:p>
<o:p>
Apart from that, it contains the node section for each view, where we specify two things. navigateValue and View. Navigatevalue specifies the command that controller specifies it to and then after receiving the command, where should he go to is specified in the view attribute which again specify the logical name of the view. So there is a slight performance impact but it provides a lot of flexibility in our application. <o:p>
<o:p>
Ok now see the functionality.<o:p>
<o:p>
We have the view and we need to move to another view. So what we do is that we should first save the state of this view. This is done by accessing the state property of the controller which is again the key-value pair so we will do something like this.<o:p>
<o:p>
Controller.State["someState"] = txtState.Text;<o:p>
<o:p>
After this we specify the navigationmethod of the controller. Something like this:<o:p>
<o:p>
((DemoController1)Controller).Form1btnNext();<o:p>
<o:p>
Where we need to call the Form1btnNext method of the controller called DemoController1. we need to cast it into appropriate type<o:p>
<o:p>
<o:p>
Now if we look in the controller class for our application, it is derived from the controllerBase class of the application and in the form1btnNext<o:p>
<o:p>
public void Form1btnNext()<o:p>
{<o:p>
// Navigate to the next view<o:p>
State.NavigateValue = "next";<o:p>
Navigate();<o:p>
}<o:p>
<o:p>
<o:p>
We are specify the navigate value and then calling the Navigate method else we would have done this <o:p>
<o:p>
Navigate(“next); <o:p>
<o:p>
Both gives the same result. In the Controller class, we would have to create a constructor that takes the navigation object. By this. We ensure a way to loosely couple our view and each view is able to know its own state. This is where the advantage of UIPAB comes into the scene. Now Through this article I tried to make sure that configuration of UIPAB in web.config file is very easy to use. Through this series of articles, I tried to make sure that it is really easy to work on UIPAB. Full web.config file is available with the zip file that I am attaching with this article.<o:p>
<o:p>
Conclusion<o:p>
<o:p>
This series of article was meant to explain all about configuration of UIPAB , why is it used and How to use it.
Submit an article or tip
