Let There Be Life!

The source code for this article can de downloaded here: https://github.com/LisburnLad/ArtificialLife/releases/tag/v1.0 

Instructions on getting up and running are given at the end of the article.

Inspired by the robot of Ex Machina (possibly the finest robot movie of all time), I too have decided to create Artificial Life. Obviously it's going to take me a few weeks to create something as complex as Ava from the film, but how hard can it be?

How To Create Intelligent Life

So how do you actually go about creating intelligent life? To be honest I don't actually know. However, I do know (look away now all of you with a fundamental religious belief) that life came about through evolution. So a computer program that models evolution would be a good place to start. 

Luckily such a program already exists: Genetic Algorithms model the natural selection process. They start with a set of instruction strings, each of which is used to form an object that can then be evaluated to see how well it performs at the task in hand. So, in our case, each instruction string would be used as the blue-print of our life form, which we would then create and evaluate to see how good it is at the problem we set it. The instruction strings in the Genetic Algorithm represent biological chromosomes.

Once the object created from each chromosome has been evaluated, to give it a fitness score, the chromosomes are then ordered by these scores. The worst performing chromosomes are discarded and the best are used to form a new generation of chromosomes. When forming the next generation, the best chromosomes are combined together in the hope of producing new chromosomes that contain the best features of their parent chromosomes. So, for our life forms, the instruction strings from two parents would be spliced together to form the instruction string for a new child which would, hopefully, outperform its parents.

When the next generation of chromosomes has been created, each is again evaluated in the same way as before, and the process continues in this way. This "survival of the fittest" selection approach should result in populations that are successively better adapted to solve the problem for which they are being evaluated. For more information on Genetic Algorithms check out the seminal book by David Goldberg.

In addition to knowing that life came about through evolution, I also know that the most evolved computer scientist brains have created C#, the finest programming language known to mankind (or to me anyway). Given this knowledge, a C# Genetic Algorithm is what we need and this looks perfect for the job:

Genetic Algorithm Framework for .Net 4.0

This Genetic Algorithm (GA) Framework allows us to simulate evolution. All we need to know now is what to evolve. Unfortunately my knowledge is once again lacking. I do know that there are a load of different Artificial Neural Network models out there, the best known of which is probably the Backpropagation Algorithm. However, while all of these Neural Networks have much to offer, I'm not 100% sure if they're the exact component required to give true Artificial Intelligence. 

Therefore I'll start with something a lot simpler: a NAND gate. Basically this can be thought of a very simple switch, whose output will be turned on, unless all of its inputs are turned on. Additionally, it has the desirable property of being a "universal" logic gate, meaning that any other logic function can be implemented by using combination of these NAND gates. Although these logic gates do give a very simple building block, they do differ from the human brain in that they are binary components, working only in 1's and 0's, whereas the brain, or the Backprop Algorithm, are analogue. Hopefully this difference wont stop us in our quest for Artificial Life!

The other thing I know about the brain is that it is massively parallel. Millions of neurons are all working at the same time to process the input signals and to generate the output responses. Unfortunately my PC has only got a couple of processors, so I'm going to have to simulate a massively parallel architecture. Similarly, the brain is a 3-dimensional object, but this sounds a bit tricky to implement, so to start with I'll stick to a simple 2-dimensional grid and see how far this get take us.

In traditional Artificial Neural Networks (ANNs), such as Backpropagation, all the connections have the same direction and information moves through the network from input to output - these are known as Feed Forward networks. Recurrent Neural Networks allow information to move in the opposite direction, so that feedback loops can take place. Which is best? Yet again I don't know (this is becoming a theme!), so I'll let the Genetic Algorithm decide on the direction of each node in the network. Since we're going to have a simple 2-dimensional grid of nodes, each node can have 4 possible directions (let's call these North, East, South and West to make things easy to visualize).

Defining the Chromosome

So, we now have a Genetic Algorithm (GA) that can simulate Evolution and a plan for a very simple Neural Network to which we can apply this evolutionary process. However, GA's don't work directly with Neural Networks, instead they work on Chromosomes that, in this case, represent the structure of the Neural Network (NN). We therefore need to encode our NN structure to give us a Chromosome.

Since each node of our network has 4 possible directions, a very simple encoding is simply to have 2-bits for each node (i.e. 00 = North, 01 = East, 11 = South and 10 = West). If we begin with a small grid of 5 x 5 nodes, then we'll have a chromosome of 50 bits in length.

So, for example, the chromosome:

01101000001110000010101000100110100001010100011111

Gives a network with the following directions:

→ ← ↓ → ↓

↑ ↑ ↑ ↑ →

← ← ↓ ↑ ↑

↑ ↑ → ↓ →

↓ → ↓ ↑ ↑

This is a very simple chromosome, with each node being represented directly. It's what's referred to as a "strong specification scheme" or "direct encoding". As the network grows in size a "weak specification scheme" or "indirect encoding" method would be more appropriate, as these tend to allow modules to be defined, but for this simple structure, the direct encoding should be sufficient.

Evaluating the Structure

Each node in the grid represents a single NAND gate and this will receive input from the 3 adjacent squares in the grid that are not the output square. So for a North orientated gate, as shown below, it will get its inputs from either side (A and B) and from below (C). 

A node at the edge of the grid will have a reduced number of inputs, so a corner node will potentially only have a single possible input. Additionally, an input will only occur if the output of the gate in the adjacent square is pointing into the current square. So, for the centre node in the grid below, it's output points South, so its potential inputs are the East, North and West nodes, shown by the red circles. However, none of these point into the centre square, so this node has no inputs. In this case all inputs are considered to be zero and the node will have a constant output value of 1.

Running the program

To run the program, do the following:

1. Download the source code from here:

 https://github.com/LisburnLad/ArtificialLife/releases/tag/v1.0 

2. Open the ArtificialLife.sln solution in Visual Studio (I'm using VS2012 but I presume that this will work in any newish version).

3. Install the Genetic Algorithm Framework for .Net 4.0

0 0 0 0 0

0 0 0 0 0

0 0 1 0 0

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0

0 1 1 1 0

0 1 1 1 0

0 1 1 1 0

0 0 0 0 0

1 1 1 0 1

1 1 1 1 1

1 1 1 1 1

0 1 1 1 1

1 1 1 0 0

Ajax Web Parts Part 4 - Dynamic Web Part Connections

Posts In This Series:

Introduction - ASP.NET AJAX and Web Parts
Ajax Web Parts Part 1 - Drag and Drop
Ajax Web Parts Part 2 - Web Part Connections
Ajax Web Parts Part 3 - Dynamic Web Parts
Ajax Web Parts Part 4 - Dynamic Web Part Connections


Download the source - Part 1
Download the source - Part 2
Download the source - Part 3
Download the source - Part 4

Introduction

Currently the dynamically created Web Parts (described in part 3) cannot be moved between zones. In addition, doing a postback results in more dynamically generated Web Parts appearing. This occurs because the Web Part Manager assigns each dynamically created Web Part a random ID when its AddWebPart() function is called. To fix this problem we need a Web Part Manager that doesn’t assign random IDs and, luckily for us, Lee Dale has created just what we’re after.

Modifying Lee’s code slightly, so that it derives from the Preview DLL’s WebPartManager, rather than the standard WebPartManager (to ensure cross browser drag and drop), gives the following:

namespace AjaxWebParts.Controls
{
  public class DynamicWebPartManager 
  : Microsoft.Web.Preview.UI.Controls.WebParts.WebPartManager
  {
    public void AddDynamicWebPart(WebPart webPart,
                Microsoft.Web.Preview.UI.Controls.WebParts.WebPartZone zone)
    {
      Internals.AddWebPart(webPart);
      Internals.SetZoneID(webPart, zone.ID);
    }
  }
}

To use this new Web Part Manager we need to make the following changes:

In our DynamicWebParts class, make the following changes:

1. change the WebPartManager alias at the top of the line to become the following:

using WebPartManager = AjaxWebParts.Controls.DynamicWebPartManager;

2. change the addition of the dynamically created Web Part to the Web Part Zone to use the DynamicWebPartManger’s function. So the current

return itsManager.AddWebPart(genericWebPart, zone, 0);

is replaced by:

itsManager.AddDynamicWebPart(genericWebPart, zone);
return genericWebPart;  

In the default.aspx page the following changes are required:

1. Add the following to the set of namespace registrations:

<%@ Register Namespace="AjaxWebParts.Controls" TagPrefix="awp" %>

2. Change the reference to the Web Part Manager from “cc1:WebPartManager” to “awp:DynamicWebPartManager”

After these changes have been made everything should now work as it should: the dynamically created Web Parts should now be able to be dragged between zones and multiple Web Parts should not appear when postbacks occur. All that is required now is to implement the connection between the dynamic Web Parts.

Creating Dynamic Web Part Connections

Once dynamic Web Parts exist, with non-random ID values, creating the connections between them is relatively straightforward. We simply need to get the connection point from each Web Part and then, if a connection can be made between the Web Parts, simply create a connection that joins the two connection points.

We therefore need to add a new function to our DynamicWebParts class to create the Web Part connection, as follows:

<br />/// <summary><br />/// Form a connection between the suplied provider and consumer web parts<br />/// </summary> <br />/// <param name="aProvider">the provider web part</param><br />/// <param name="aConsumer">the consumer web part</param> <br />public void FormWebPartConnection(WebPart aProvider, WebPart aConsumer)<br />{<br /> if (aProvider != null && aConsumer != null)<br /> {<br /> // get the connection points collections for each web part<br /> ProviderConnectionPointCollection providerConnectionPoints = itsManager.GetProviderConnectionPoints(aProvider);<br /> ConsumerConnectionPointCollection consumerConnectionPoints = itsManager.GetConsumerConnectionPoints(aConsumer);<br /><br /> // each web part only has a single connection point, so take the first one of each<br /> ProviderConnectionPoint provPoint = providerConnectionPoints[0];<br /> ConsumerConnectionPoint connPoint = consumerConnectionPoints[0];<br /><br /> if (provPoint != null && connPoint != null)<br /> {<br /> // check that these web parts can be connected<br /> if (itsManager.CanConnectWebParts(aProvider, provPoint, aConsumer, connPoint))<br /> {<br /> // create the connection<br /> WebPartConnection newconn = new WebPartConnection();<br /> newconn.ID = "AutoConnection";<br /> newconn.ConsumerID = aConsumer.ID;<br /> newconn.ProviderID = aProvider.ID;<br /> itsManager.StaticConnections.Add(newconn);<br /> }<br /> }<br /> }<br />}<br />

Finally we need to call this function from our default.aspx.cs code-behind file. The Page_Init() function now becomes:

<br />protected void Page_Init(object sender, EventArgs e)<br />{<br /> // create an instance of the dynamic web part class<br /> DynamicWebParts dynamicWebParts = new DynamicWebParts(this);<br /> dynamicWebParts.Manager = WebPartManager1;<br /><br /> // create 2 web parts<br /> WebPart provider = dynamicWebParts.AddWebPartToZone("WebPartZone1", <br /> "UserControls/Provider.ascx", <br /> "Dynamic Provider");<br /> WebPart consumer = dynamicWebParts.AddWebPartToZone("WebPartZone2", <br /> "UserControls/Consumer.ascx", <br /> "Dynamic Consumer");<br /><br /> // create a connection between the web parts<br /> dynamicWebParts.FormWebPartConnection(provider, consumer);<br />}<br />

Now, when the Web Page is run, the dynamically generated Web Parts will be connected. Typing a value into the dynamic provider's text box and clicking the button will result in the value being displayed in the dynamically created consumer Web Part.

Creating Dynamic Web Part Zones

Now that we can dynamically create Web Parts, lets move on to create the rest of the page dynamically, starting with the Web Part Zones.
This is very straightforward – it’s simply a case of creating an instance of a WebPartZone and adding it to the page (note that the WebPartZone that gets created is from the Preview DLL, due to the alias that was declared).

The DynamicWebParts class member function therefore appears as follows:

<br />/// <summary><br />/// Create a new web part zone and give it the supplied title<br />/// (the title is also used as the ID of the zone)<br />/// </summary><br />/// <param name="aZoneTitle"></param><br />/// <returns></returns><br />public WebPartZone CreateWebPartZone(string aZoneTitle)<br />{<br /> WebPartZone webPartZone = new WebPartZone();<br /> webPartZone.ID = aZoneTitle.Replace(" ", "");<br /> webPartZone.HeaderText = aZoneTitle;<br /> return webPartZone;<br />} <br />


Similarly, we can create the WebPartManager:

<br />/// <summary><br />/// Create a new dynamic web part manager<br />/// </summary><br />/// <returns></returns><br />public DynamicWebPartManager CreateWebPartManager()<br />{<br /> DynamicWebPartManager webPartManager = new DynamicWebPartManager();<br /> webPartManager.ID = "WebPartManager1";<br /> return webPartManager;<br />}<br />


and the UpdatePanel:

<br />/// <summary><br />/// Create a new update panel with the supplied ID<br />/// </summary><br />/// <param name="aID"></param><br />/// <returns></returns><br />public UpdatePanel CreateUpdatePanel( string aID )<br />{ <br /> UpdatePanel updatePanel = new UpdatePanel();<br /> updatePanel.ID = aID;<br /> return updatePanel;<br />}<br />

Since all the page components can now be created dynamically, the static components in the page markup are no longer required. This page therefore simplifies down to:

<br /> <form id="form1" runat="server"><br /> <div><br /> <h2>Click and hold the Web Part title to drag it to the second Web Part Zone:</h2> <br /> <asp:button id="ResetButton" runat="server" text="Reset" onclick="ResetButton_Click"> <br /> <asp:scriptmanager id="ScriptManager1" runat="server"> <br /> <asp:placeholder id="PlaceHolder1" runat="server"><br /> </div><br /> </form><br />

Note that a PlaceHolder component has been added to give us somewhere to add our dynamic components.

In the Default.aspx.cs code behind file the Page_Init function now becomes:

<br />protected void Page_Init(object sender, EventArgs e)<br />{<br /> // create an instance of the dynamic web part class<br /> DynamicWebParts dynamicWebParts = new DynamicWebParts(this);<br /><br /> // create a new update panel<br /> UpdatePanel updatePanel = dynamicWebParts.CreateUpdatePanel("DynamicUpdatePanel");<br /><br /> // add the web part manager to the update panel<br /> updatePanel.ContentTemplateContainer.Controls.Add(dynamicWebParts.Manager);<br /><br /> // add 2 web part zones to the update panel<br /> WebPartZone dynamicZone1 = dynamicWebParts.CreateWebPartZone("Dynamic Zone 1");<br /> updatePanel.ContentTemplateContainer.Controls.Add(dynamicZone1);<br /> WebPartZone dynamicZone2 = dynamicWebParts.CreateWebPartZone("Dynamic Zone 2");<br /> updatePanel.ContentTemplateContainer.Controls.Add(dynamicZone2);<br /><br /> // add the update panel to the page<br /> PlaceHolder1.Controls.Add(updatePanel);<br /><br /> // create 2 web parts<br /> WebPart provider = dynamicWebParts.AddWebPartToZone(dynamicZone1.ID, <br /> "UserControls/Provider.ascx", <br /> "Dynamic Provider");<br /> WebPart consumer = dynamicWebParts.AddWebPartToZone(dynamicZone2.ID, <br /> "UserControls/Consumer.ascx", <br /> "Dynamic Consumer");<br /><br /> // create a connection between the web parts<br /> dynamicWebParts.FormWebPartConnection(provider, consumer);<br />}<br />

And, since the page markup no longer defines a WebPartManager, this needs to obtained dynamically when needed. So the Page_load function now changes to become:

<br />protected void Page_Load(object sender, EventArgs e)<br />{<br /> if (!Page.IsPostBack)<br /> {<br /> // set the display mode to "Design" to allow drag and drop<br /> WebPartManager manager = WebPartManager.GetCurrentWebPartManager(this);<br /> if (manager != null)<br /> {<br /> WebPartDisplayMode mode = manager.SupportedDisplayModes["Design"];<br /> if (mode != null)<br /> {<br /> manager.DisplayMode = mode;<br /> }<br /> }<br /> }<br />}<br />


Click here to see this in action.


Putting this all together results in an ASP.NET AJAX page, featuring 2 Web Part Zones and 2 dragable, connected, Web Parts. Everything has now been created dynamically and is therefore just what’s required for populating tab pages.

Ajax Web Parts Part 3 - Dynamic Web Parts

Posts In This Series:

Introduction - ASP.NET AJAX and Web Parts
Ajax Web Parts Part 1 - Drag and Drop
Ajax Web Parts Part 2 - Web Part Connections
Ajax Web Parts Part 3 - Dynamic Web Parts
Ajax Web Parts Part 4 - Dynamic Web Part Connections


Download the source - Part 1
Download the source - Part 2
Download the source - Part 3
Download the source - Part 4




Introduction

So far, in this series on Ajax Web Parts, all the components have been created at design time. The Web Part Zones, the Web Parts themselves, and the connections between them, have all been added statically to the page markup.

In order to achieve our ultimate goal, of movable Web Parts in a user created tab framework, we now need to change to using dynamically created components:

• Web Part Zones need to be dynamically created so that, eventually, they can be used to populate each tab page.


• Web Parts and their connections need to be generated at run time to populate the Web Part Zones.

Therefore, we will now investigate how the previous project can be changed to add these dynamic components.



Creating Dynamic Page Components

The easiest way to create dynamic page components is by copying static components – that is, firstly create the required components in the ASP.NET markup and then, once this is working, copy the structure to create the same components dynamically.
We will use this approach to replace the Web Part components that were statically created in the last posts, with a new class that can dynamically generate the same components.



A Dynamic Web Part Class

Rather than simply adding everything to the web form’s code-behind file, we will create a class to create the dynamic components. So first of all, we need to add a new class to the project as follows:

1. Right-click on the project’s “app_code” node and choose “Add New Item”.
2. In the dialog that appears choose to add a new class and give this the name “DynamicWebParts.cs”.
3. Once the class has been added to the project, change the constructor so that it takes an instance of the page and add a property to hold a reference to this value. This is required to give us something to add our components to. The page comes from the System.Web.UI namespace, so a “using” line needs to be added for this.

At this stage the class should look as follows:


<br />using System.Web.UI;<br /><br />public class DynamicWebParts<br />{<br /> /// <summary><br /> /// the page to which components will be added<br /> /// </summary><br /> private Page itsPage;<br /><br /> public DynamicWebParts(Page aPage)<br /> {<br /> itsPage = aPage; <br /> }<br />}<br />

In addition to a page, to which the Web Parts can be added, the other thing that is required to create dynamic Web Parts is a Web Part Manager. For now we will simply pass through the static Web Part Manager that exists on the page and store this into a property as follows:

  private WebPartManager itsManager;
  public WebPartManager Manager
  {
    set { itsManager = value; }
  }

Namespace Selection

If you remember from the previous posts, to get cross-browser drag and drop support we needed to use the Web Part Manager from the Microsoft Web Preview release. Therefore we need to use the same version here in our class. Therefore, at the top of the page the following “using” statement is required:

using Microsoft.Web.Preview.UI.Controls.WebParts;

This namespace is used to give us the Web Part Manager and Web Part Zones needed for cross-browser drag and drop. However, the Web Parts themselves still come from the standard System.Web.UI.WebControls.WebParts namespace. Therefore, to avoid a clash, we need to explicitly state that the Web Part Manager and Web Part Zones come from Preview DLL. This can be done by specifying the full namespace every time we refer to the WebPartManager and WebPartZones. However this is rather cumbersome.

A more elegant approach is to add an alias so that both WebPartManager and WebPartZone will always reference the Preview DLL's versions. To do this the following lines should be added:

using WebPartManager = Microsoft.Web.Preview.UI.Controls.WebParts.WebPartManager;
using WebPartZone = Microsoft.Web.Preview.UI.Controls.WebParts.WebPartZone;

(Another approach that can be used to specify which DLL to use, when referring to a control, is to use tag mapping in the web.config file. However, this will only work for controls declared in markup and is therefore not appropriate for dynamically created controls. See David Barkol's blog for details)



Dynamic Web Parts

Everything is now in place to allow us to dynamically add some Web Parts to the page. As a first step, let’s replace the static Provider and Consumer Web Parts that were created in the last part of the series. Both of these Web Parts were formed by taking User Controls and adding them to Web Part Zones to create Web Parts. We will use a similar approach when dynamically generating the Web Parts. The function to take a User Control and add it to a Web Part Zone is shown below:


<br />/// <summary><br />/// Create a web part from the specified control and add it to the specified zone.<br />/// </summary><br />/// <param name="aZoneName">the zone to which the control will be added</param><br />/// <param name="aControlName">the virtual path to the control file</param><br />/// <param name="aWebPartTitle">the title to give the newly created Web Part</param><br />/// <returns></returns><br />public WebPart AddWebPartToZone(string aZoneName, <br /> string aControlPath, <br /> string aWebPartTitle)<br />{<br /> // load the control from the supplied path<br /> Control control = itsPage.LoadControl(aControlPath);<br /><br /> // remove spaces from the control's path to form the ID<br /> control.ID = aWebPartTitle.Replace(" ", "");<br /><br /> // find the specified web part zone in the manager's list of zones<br /> WebPartZone zone = itsManager.Zones[aZoneName] as WebPartZone;<br /> if (zone != null)<br /> {<br /> GenericWebPart genericWebPart = itsManager.CreateWebPart(control);<br /> genericWebPart.Title = aWebPartTitle;<br /><br /> // add the web part to the zone<br /> return itsManager.AddWebPart(genericWebPart, zone, 0); <br /> }<br /><br /> // the web part could not be added to the zone<br /> return null;<br />}<br />

Notice how the steps required to dynamically add a Web Part closely resemble those used to statically add one:

· once again a User Control is loaded (using the Page’s LoadControl function)
· a Web Part is then created (by calling the Web Part Manager’s CreateWebPart function) and added to a Zone (using the Web Part Manager’s AddWebPart function).

Other points to note here are:
1. We’ve created a unique ID for control by simply taking the title supplied for the Web Part and removing any spaces from it.
2. To get the Web Part Zone we need to search the Web Part Manager’s list of Zones until the supplied name is found.
3. The Web Part Manager’s AddWebPart function takes a copy of the supplied Web Part and returns a reference to the copy. Therefore it is this that needs to be returned to get access to the Web Part that actually exists on the page (rather than the Web Part that was created using CreateWebPart).


All that’s required now is to actually use this new function to programmatically generate some Web Parts. Therefore, back in the Default.aspx.cs code behind file, add the following:

<br />protected void Page_Init(object sender, EventArgs e)<br />{<br /> // create an instance of the dynamic web part class<br /> DynamicWebParts dynamicWebParts = new DynamicWebParts(this);<br /> dynamicWebParts.Manager = WebPartManager1;<br /><br /> // create 2 web parts<br /> dynamicWebParts.AddWebPartToZone("WebPartZone1", <br /> "UserControls/Provider.ascx", <br /> "Dynamic Provider");<br /> dynamicWebParts.AddWebPartToZone("WebPartZone2", <br /> "UserControls/Consumer.ascx", <br /> "Dynamic Consumer");<br />}<br />

This creates an instance of our new class, sets the Web Part Manager to the one that exists in the markup and then creates 2 Web Parts – a Provider, which is added to the first Web Part Zone and a Consumer, which is added to the second Web Part Zone.

Running this should give the following output:





Click here to see this in action.

Note, that at this stage, the dynamic Web Parts cannot be moved between zones. Trying to move them results in more Web Parts appearing. This is a result of the way in which the standard Web Part Manager assigns IDs to the Web Parts and we'll look at this more closely in the next post.


Conclusion

Both statically and dynamically created Web Parts now exist on the page. The statically created Web Parts have a connection between them; any text typed into the input field of the provider Web Part will appear in the label of the consumer Web Part when the button is clicked. The dynamically created Web Parts are not yet connected and, as we'll see in the next part of this series, creating this connection is not as straightforward as it should be (this seems to be a recurring theme!). In addition, drag and drop doesn't yet work for the dynamically created Web Parts - this is something that will also be resolved in the next post.

Ajax Web Parts Part 2 - Web Part Connections

Posts In This Series:

Introduction - ASP.NET AJAX and Web Parts
Ajax Web Parts Part 1 - Drag and Drop
Ajax Web Parts Part 2 - Web Part Connections
Ajax Web Parts Part 3 - Dynamic Web Parts
Ajax Web Parts Part 4 - Dynamic Web Part Connections


Download the source - Part 1
Download the source - Part 2
Download the source - Part 3
Download the source - Part 4



Introduction

The first part of this series introduced the components required to perform basic Web Part drag and drop.

In that post a simple Web Part was created from the Calendar component. This was then used to illustrate how a Web Part could be moved between Web Part Zones that had been created at design time.

Although the Calendar component was useful for illustrating how a Web Part can be moved between zones, it doesn’t really give a realistic view of how Web Parts would be used in a real-world situation. For this we need something slightly more complex – a pair of Web Parts that communicate via a connection.



Click here to see what will be created.

Web Part Connections

Two Web Parts are required to form a Web Part Connection; a Provider Web Part to initiate the connection and a Consumer Web Part to receive the connection.

For our example, both of these Web Parts can be formed by creating a standard User Control and then adding it to a WebPartZone (by dragging it from the Solution Explorer window and dropping it into the WebPartZone in the Design view of the Web Form).

For simplicity the Provider part consists of only 2 items: a text box to enter a string and a button to send the string to the Consumer part. So, in the markup, the Provider is given by:


<br /><%@ Control Language="C#" <br /> AutoEventWireup="true" <br /> CodeFile="Provider.ascx.cs" <br /> Inherits="User_Controls_Provider" %><br /><asp:TextBox ID="TextBox1" runat="server" /> <br /><asp:Button ID="Button1" runat="server" Text="Button" /><br />



The Consumer only contains a label, to display the string that is received from the Provider. Its markup is therefore as follows:



<br /><%@ Control Language="C#" <br /> AutoEventWireup="true" <br /> CodeFile="Consumer.ascx.cs" <br /> Inherits="User_Controls_Consumer" %><br /><span>Message: </span><br /><asp:Label ID="Label1" runat="server" Font-Bold="true" ></asp:Label><br />

To allow these Web Parts to communicate we must now define the connection between them. This is done by creating an interface that specifies the type and name of parameters that may be passed between the Web Parts.

In our case we are only sending a string (the text entered into the text box) from the Provider to the Consumer. The interface (in the sample download code this is defined in IWebPartInterface.cs within the App_Code directory) therefore defines that the Consumer can get a single string, called Message, from the Provider and appears as follows:

public interface IWebPartInterface
{
  string Message { get;}
}

In the code-behind the User Controls must specify the part they play in the connection.

The Provider, as its name suggests, must provide the interface. It does this by having a function that returns the interface. This function is identified by using the ConnectionProvider attribute. Each end of the connection is referred to as a Connection Point. The ConnectionProvider attribute takes a parameter that assigns a name to the connection point (for our provider we’ve radically called it “ProviderConnectionPoint”).

Since, in our case, the Provider class inherits from the IWebPartInterface the member function can simply return an instance of its class (i.e. it returns this).

Finally, the Provider needs to actually return some data to give to the consumer. In our case this is simply the value that gets entered into the text box and, from the interface we’ve defined, we know that this value should be labelled as Message.

Therefore the complete code-behind of the Provider class is as follows:

public partial class User_Controls_Provider
: System.Web.UI.UserControl, IWebPartInterface
{
  [ConnectionProvider("ProviderConnectionPoint")]
  public IWebPartInterface GetProviderData()
  {
    return this;
  }

  public string Message
  {
    get { return TextBox1.Text; }
  }
}

In the Consumer the ConnectionConsumer attribute is used to specify that the SetProviderData method is used to get the interface and store it into a local variable.

Once the connection has been established between the Provider and the Consumer, the Consumer can use it to set the text of its label and this is done at the pre-render stage of the page lifecycle.

public partial class User_Controls_Consumer
: System.Web.UI.UserControl
{
  IWebPartInterface itsProvider = null;

  [ConnectionConsumer("ConsumerConnectionPoint")]
  public void SetProviderData(IWebPartInterface aProviderData)
  {
    itsProvider = aProviderData;
  }

  protected override void OnPreRender(EventArgs e)
  {
    if (itsProvider != null)
    {
      Label1.Text = itsProvider.Message;
    }
    base.OnPreRender(e);
  }
}

Finally, the connection needs to be specified in the Web Part Manager. This needs to define which Web Part acts as the provider of the connection and which as the consumer. So, for the Web Parts we’ve defined, the markup appears as follows:

<br /><cc1:WebPartManager ID="WebPartManager1" runat="server"><br /> <StaticConnections><br /> <asp:WebPartConnection ID="WebPartConnection1" <br /> ProviderID="Provider1" <br /> ConsumerID="Consumer1" /> <br /> </StaticConnections> <br /></cc1:WebPartManager><br />


Putting this all together results in a Web Page consisting of 2 Web Parts that can be dragged between the Web Part Zones and that can communicate. Entering some text into the provider Web Part’s text box and clicking on the button results in the text appearing in the consumer Web Part, as shown below:

Click here to see this in action.

Conclusion

This post has expanded our Web Part example to show how 2 Web Parts can communicate using a Web Part Connection. Everything has still been created statically at design time. In the next post I’ll look at how these Web Parts and Web Part Zones can be created dynamically to form a tab framework.


Links

More information on Web Part Connections can be found at the following:

http://www.carlosag.net/Articles/WebParts/connectionsTutorial.aspx

http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.webpartconnection.aspx

Ajax Web Parts Part 1 - Drag and Drop

Posts In This Series:

Introduction - ASP.NET AJAX and Web Parts
Ajax Web Parts Part 1 - Drag and Drop
Ajax Web Parts Part 2 - Web Part Connections
Ajax Web Parts Part 3 - Dynamic Web Parts
Ajax Web Parts Part 4 - Dynamic Web Part Connections


Download the source - Part 1
Download the source - Part 2
Download the source - Part 3
Download the source - Part 4

Introduction
In this post I'm going to describe the very basic steps required to get Web Parts drag and drop up and running from scratch. This will use a Calendar item, added to a Web Part Zone, to make a generic Web Part. This is the standard demonstration of Web Parts that has been used in a multitude of other Web Part tutorials - it's replication here is purely to get the basic components in place before moving on to other, more advanced, topics.

Click here to see what will be created.

Required Components
At present, due to the evolving nature of the subject, there are a large number of different versions of ASP.NET and its related components. These components can appear in releases with titles such as “futures”, “extensions” and “Community Technology Previews (CTPs)". As a result, one of the major challenges when working with ASP.NET is finding the appropriate set of components to use – each release appears to have its own unique fixes and quirks and, consequently, it can be difficult to find the correct combination to achieve the desired results. Hopefully ASP.NET 4.0 will fix all the bugs and tie everything together!

Therefore, when working with ASP.NET AJAX and Web Parts we will require more than the standard ASP.NET framework; extra components are needed either to add functionality or to fix problems in the current release. To begin with we will start with a standard system and add these extra components as required.

Initially, to follow along with the code in these posts, you will require 2 things:

1. Visual Studio 2008 or Visual Web Developer Express
2. The ASP.NET AJAX Control Toolkit

Creating the initial project
From the file menu, select "New Web Site" and then choose "AJAX Control Toolkit WebSite" from the list of available options:

Adding the Web Part Components
Now we need to add a few components to the page to give us something to work with.
From the toolbox, when in design or split mode, drag the following items onto the default.aspx page:
From the WebParts toolbox tab:

• 1 x Web Part Manager
• 2 x Web Part Zones

Then, from the Standard toolbox tab, drag a Calendar component and drop it into the first Web Part Zone - this will automatically convert the Calendar into a generic Web Part.

After the addition of these items, the default.aspx page should look as shown below (it also includes a ToolkitScriptManager which is there as a consequence of the initial project choice we made. At present this isn't being used, but will be required later.)

Before we can actually run this project, and get the drag and drop behaviour that we’re after, we need to make a small addition to the code behind.

Display Modes and Personalization
If you were to run the project in its current state, you would see one of two things - either you would get a database error, or you would see the Calendar component, but would be unable to change its position.

The reason why drag and drop is not yet possible is due to the display mode setting of the Web Part Manager. Display modes are used to define what operations can be performed on the Web Parts; the default display mode is "Browse" and this is the mode currently used by our page. In this mode it's only possible to do basic operations, such as minimize and close; it's not possible to perform drag and drop. To enable drag and drop requires, at a minimum, the display mode to be changed to "Display".

However, things aren't quite so simple. When web parts are moved on the page it's necessary to save the information about their new positions so that they can be restored to these locations the next time the page is rendered. This information is stored into a personalization table in a database. Thus, to enable the more advanced features of Web Parts, such as drag and drop, requires a database to be available. If you haven't yet got a database the easiest option is to download SQL Server Express.

To set the Web Part Manager’s display mode, add the following code into the Default.aspx.cs file:

protected void Page_Load(object sender, EventArgs e)
{
  if (!Page.IsPostBack)
  {
    // set the display mode to "Design" to allow drag and drop
    WebPartDisplayMode mode = WebPartManager1.SupportedDisplayModes["Design"];
    if (mode != null)
    {
      WebPartManager1.DisplayMode = mode;
    }
  }
}

If this is the first time that the page is being rendered (i.e. not a postback), then this code checks the Web Part Manager to see if the "Design" mode is contained in its list of supported display modes. If it is, then it sets this to be the current display mode.

We now have everything in place to enable drag and drop. Press F5 to run the project and hopefully you should see the following output:

If you have run this using Internet Explorer, drag and drop functionality should now be enabled:
- when the cursor is hovered over the title bar it should change to the directional cursor and clicking and holding on the Calendar web part's title bar should enable it to be selected and dragged to the second Web Part Zone.

However, with the current release of ASP.NET 3.5, if you have run this in a browser other than IE (e.g. Firefox), then the chances are that the drag and drop won't be working - to fix this we need to make another modification.


Web Part Drag and Drop in Firefox
For some reason Microsoft have chosen not to include the fix for Firefox (and other non-IE) browsers in the latest releases of the ASP.NET framework. To get things working in all browsers requires the download of the Microsoft ASP.NET Futures (July 2007) Release - obviously this is a technology preview release and is therefore not supported for production sites - however, the alternative is to not have drag and drop support for all non-Microsoft browsers, so you need to choose which of these is the most important to you.

Once this futures release has been downloaded, its components need to be added to your Visual Studio toolbox. To do this, you need to do the following steps:

1. In the toolbox window, move the cursor into the bottom tab pane and right click to bring up the context menu. From this choose "Add Tab" and create a new tab for the futures release.


2. From within this new tab pane, select "Choose Items.." from the right-click context menu.


3. In the dialog that appears choose browse and locate the futures DLL (mine was downloaded to C:\Program Files\Microsoft ASP.NET\ASP.NET Futures July 2007\v1.3.61025\3.5).Click on OK once all the components of this DLL have been selected. All these components should then be added to the new tab of the toolbox, as shown below.

As you can see, the toolbox now contains both a WebPartManager and WebPartZone that have been added from the Futures release. All we need to do now are replace the standard versions of these that we'd added already with these new Futures versions and that should fix our Web Parts drag and drop for all browsers.

AJAX Enabling The Web Parts
We've only one thing left to do, and that's remove the annoying postbacks that occur when the Web Parts are moved. To do this we simply need to wrap everything in an UpdatePanel from the AJAX Extensions tab of the toolbox. We already have a ScriptManager present from the AJAX Control Toolbox - however, for consistency, I've chosen to remove this and replace it with the standard version. Once everything is in place, the body of my default.aspx file now looks as follows:

<br /><br /><br /> <form id="form1" runat="server"><br /><br /> <div><br /><br /> <asp:scriptmanager id="ScriptManager1" runat="server"><br /><br /> </asp:ScriptManager><br /><br /> <asp:updatepanel id="UpdatePanel1" runat="server"><br /><br /> <contenttemplate><br /><br /> <cc1:webpartmanager id="WebPartManager1" runat="server"><br /><br /> </cc1:WebPartManager><br /><br /> <cc1:webpartzone id="WebPartZone1" runat="server"><br /><br /> <zonetemplate><br /><br /> <asp:calendar id="Calendar1" runat="server"></asp:Calendar><br /><br /> </zonetemplate><br /><br /> </cc1:WebPartZone><br /><br /> <cc1:webpartzone id="WebPartZone2" runat="server"><br /><br /> </cc1:WebPartZone><br /><br /> </contenttemplate><br /><br /> </asp:UpdatePanel><br /><br /> </div><br /><br /> </form><br /><br /><br /><br />

Click here to see this in action.

This concludes the introduction to Web Parts. In future posts I'll expand apon this simple project to show how Web Parts can be combined with both the ASP.NET AJAX framework and the ASP.NET AJAX Toolkit Tab component.

ASP.NET AJAX and Web Parts

Posts In This Series:

Introduction - ASP.NET AJAX and Web Parts
Ajax Web Parts Part 1 - Drag and Drop
Ajax Web Parts Part 2 - Web Part Connections
Ajax Web Parts Part 3 - Dynamic Web Parts
Ajax Web Parts Part 4 - Dynamic Web Part Connections


Download the source - Part 1
Download the source - Part 2
Download the source - Part 3
Download the source - Part 4



Introduction

In my quest to create a database capable of storing anything and everything (see earlier posts), my attention over the last few months has turned from the back end to the front end UI.

One obvious way to display a set of disparate information is to use a Web Portal style framework - a set of widgets (small window components) within a tab framework - the tabs can be used to represent the general categories and each widget can be used to display a sub-set of information for that category. Since I’m coming from an ASP.NET background, Web Parts sounded like a perfect fit for the implementation of these widgets, and the Tab Control, from the ASP.NET AJAX Toolkit, sounded like the ideal way to wrap all these Web Parts together.

In theory, the creation of this Web Portal sounded like it would be a breeze - just drop a few Web Part Zones onto the Tab Control, and populate them with the Web Parts to show information from each category. In reality, as usual, things turned out to be not quite so simple. Over the next few posts I’m going to describe the creation of a simple version of this Web Portal and highlight the problems, and workarounds, involved with each stage.

To start I’ll be describing the very basics of getting Web Parts up and running, before moving onto some more complex issues, such as dynamically generating the Web Parts and creating new tab pages on demand.

The content of these posts won’t really provide any information that can’t be found elsewhere, however I hope that by bringing it all together, into a single place, that this will be of benefit to some - certainly it would have helped me. As mentioned, most of the stuff concerning the dynamic creation of Web Parts can be found in other locations and, when I can remember where I obtained information from, I’ll try and reference these other sources. One things that these posts won’t be are in-depth overviews of either Web Parts or ASP.NET AJAX - a basic knowledge of these is assumed - if you’d like more information on either of these topics, I can recommend the books shown in the reading list.

Using SemWeb with MySQL

Getting SemWeb to work with MySQL is pretty much the same as for SQLite (see the last post). Again, using the news.rdf file from Mozilla, the command line to enter data into the MySQL database now becomes:

rdfstorage news.rdf --out "mysql:rdf:database=news;username=test"

This assumes that a new database (schema) called "news" has been created in MySQL and that a user "test" exists that doesn't require a password (both these things can be done using the MySQL Administrator UI).

Initially running this command line in the installed version of the SemWeb\bin directory results in the following error being generated:

System.IO.FileNotFoundException: Could not load file or assembly 'MySql.Data, Version=1.0.8.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The system cannot find the file specified.


This error means that the MySQL.Data.dll is missing, so the first step is to get this from MySQL ADO.Net Data Provider 5.0.7

After placing this DLL in the bin directory and running the command line again, the following error will appear:

System.IO.FileLoadException: Could not load file or assembly 'MySql.Data, Version=1.0.8.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)


In this case the important part is the "manifest definition does not match the assembly reference" bit - as happened with the SQLite DLL, this MySQL DLL is newer than the version that was used to build the SemWeb.MySQLStore.dll and so the 2 DLLs are incompatible. We need to rebuild this SemWeb DLL.


The steps to do this are as follows:

• Open the SemWeb solution in Visual Studio
• Add a new project of type "Class Library" and called "SemWeb.MySQLStore"
• Delete the default "Class1.cs" that gets added to the project
• Choose to add an existing item to the project and pick "MySQLStore.cs" from the SemWeb\src directory
• Add a reference to the "MySQL.Data.dll " that should already be in the SemWeb\bin directory
• Add a reference to the SemWeb project
• In the project properties, set the output path to the SemWeb\bin directory

These are the exact same steps that were required for the SQLiteStore DLL (although obviously referencing different files). However, building the MySQLStore DLL now results in the following compiler error:

The type or namespace name 'MySqlConnection' could not be found (are you missing a using directive or an assembly reference?)

To fix this error the following needs to be added to the top of the MySQLStore.cs file:

using MySql.Data.MySqlClient;

So the complete set of using directives at the top of the file should now appear as:

using System;
using System.Collections;
using MySql.Data.MySqlClient;
using System.Data;

The project should now rebuild successfully and the new SemWeb.MySQLStore.dll should now appear in the SemWeb\bin directory.

Unfortunately this still isn't the end of the process - running the command line again results in the following error:

MySql.Data.MySqlClient.MySqlException: Table 'news.rdf_statements' doesn't exist

The DLL is now ok, its just that the database that its creating has a few problems; inspecting the database in MySQL Administrator shows that the "rdf_literals" and "rdf_entities" tables have been created but the "rdf_statements" table hasn't been made.

Setting the SEMWEB_DEBUG_SQL environment variable (type "set SEMWEB_DEBUG_SQL=1" at the command prompt) and then running the command line again generates some debug information (alternatively put a break point on the "
CreateTable" function in the SQLStore.cs file and run the program in the debugger, after first setting up the command line arguments in the project properties). The error generated is:

System.FormatException: Input string was not in a correct format.

This is caused by the SemWeb database "Open" function (from MySQLStore.cs) querying the version of the database and then trying to set this into the .NET Version class; however, the version string returned from my version of MySQL is "5.0.41-community-nt" and this doesn't match with the expected .NET version string format, which is expecting only integers seperated by a period character ('.') - hence an error is thrown on the first call to "Open" and so the creation of the first database table ("rdf_statements") fails.

To fix this I've just put a try-catch around the setting of the version string, so basically I just ignore when the version can't be set.

private void Open()
{
  if (connection != null)
    return;
  MySqlConnection c = new MySqlConnection(connectionString);
  c.Open();
  connection = c; // only set field if open was successful

  using (IDataReader reader = RunReader(@"show variables like 'version'"))
  {
    reader.Read();
    try
    {
      version = new Version(reader.GetString(1));
    }
    catch(Exception e)
    {
      if (Debug) Console.Error.WriteLine(e.Message);
    }
  }
}

Finally, rebuilding the SemWeb DLL and re-running the command line successfully adds the RDF to the database:

news.rdf 0m0s, 81 statements, 1728 st/sec
Total Time: 0m2s, 81 statements, 30 st/sec