Staff DotNet Blogs

Communicating web parts by code is performed by using the Provider-Consumer pattern.  In this pattern one web parts acts as a provider exposing a set of public members (properties and methods) to be accessed by one or more consumers.  The pattern exposes public members set by implementing an interface (we are going to called this interface as “communication interface”)  To complete the communication process you must instruct SharePoint about how to connect the provider and consumer web parts by creating what we called “connection points”.  We are going to discuss about this later.

In order to explain this web parts communication process let’s suppose you need to pass a list of strings from one web part to another (I’m going to assume some basic knowledge about programming web parts for SharePoint). 

The first step for communicating the web parts is defining the “communication interface”:

public interface IStaffDotNetCommunicationContract

{

    List<string> SelectedData { get; set; }

}

We are exposing here a property called SelectedData which returns a list of strings (this method is going to be called by the Consumer Web Part in order to get that list)

Once you have defined the interface you must be sure that you implement the interface at the Provider Web Part (as shown below):

public class StaffDotNetProviderWebPart : System.Web.UI.WebControls.WebParts.WebPart, IStaffDotNetCommunicationContract

{

    //All the Web Part's Code goes here

}

After that, you have to set the Connection Point to the Provider Web Part.  This connection point is a method which is going to be use by SharePoint to automatically connect this webpart with its consumers. This method must return an object whose type is the communication interface created previously. You must annotate the method with the ConnectionProvider attribute in order for SharePoint to know that this is the method to invoke to connect this web part with its consumers:

[ConnectionProvider("Name", "ID")]

public IStaffDotNetCommunicationContract StaffDotNetCommunicationPoint()

{

return this as IStaffDotNetCommunicationContract;

}

Now you have to create the Connection Point for the Consumer Web Part.  In order to do that you have to define a member at the consumer web part whose type is the communication interface and you have to create a method annotated with the ConnectionConsumer attribute (this method is going to be used by SharePoint to set a reference to the provider web part from the consumer web part):

IStaffDotNetCommunicationContract webPartProvider;

[ConnectionConsumer("Name", "ID")]

public void ReceiveProviderData(IStaffDotNetCommunicationContract provider)

{

webPartProvider = provider;

}

 

Once this is done, you can access the data exposed by the provider from the consumer by calling the appropriated communication interface member:

Property.JPG

Deploying the post sample

Code snippets at this post have been taken from the sample accompanying this post. 

Again, I’m going to assume some basic knowledge about deploying SharePoint solutions.  

Then, once you build and deploy the solution and once you have added the two web parts including in the sample to a new page in a SharePoint web site, you can connect the Provider Web Part to the Consumer Web Part by following the navigation path shown at the following picture:

ConnectionsImage.JPG

To verify if everything works fine, publish your page, select some items of the Provider Web Part and then click “Send Data”.  The Consumer Web Part will display the selected items from the Provider Web Part.

And that’s It. It's a simple and quick way to communicate your web parts.

Here’s the code with the example shown in this post.

See you soon!

Congratulations to our workmate Antonio Zamora for winning the second place at VMWare Toolkit for Windows Scripting contest.  Antonio submitted a script called "VMWare Infrastructure Power Documenter" which is a reporting tool for VM Infrastructure built on top VMWare Infrastructure Power Shell Tool Kit and Power Tools for Open Xml suite.

Well done Toño!!!!!
Carlos Torres has published this interesting and useful sample about integrating SQL Server 2005 Service Broker with .NET Framework based applications.  Check it out here
Are you about to start a WSS 2.0 to WSS 3.0 migration process? Have you already started and you are somehow stuck in the middle? Don't worry, I think this article could help you. It describes the necessary steps to perform in order to implement a sucessful migration from WSS 2.0 to WSS 3.0. Download it here. Hope this helps!!!

Welcome to this second post in the “Using STSADM tool for administering MOSS 2007” series.  As stated in the first post, the STSADM command-line tool provides access to the complete set of Microsoft Office SharePoint Server 2007 administering operations. In this second post of the series we are going to review the permissions and requirements necessary to run STSADM as well as the common syntax for invoking administering operations.

Permisission and requirements

There are basically two things you must have in mind when working with STSADM:

·         STSADM must be run on the server where MOSS is installed.

·         You must me a member of the local Administrators group on that server.

Common Syntax

When you invoke STSADM, you supply an operation and a set of command-line parameters as shown below:

-operation OperationName –[parameter] ParameterValue

Tip:  If a value you need to use with the command-line tool includes a space or a character that is treated as special character by command-line interface, such as the backslash symbol (/), you can enclose the string in quotation marks (“). For example, if the URL to a site is http://my site, you can enter the URL as “http://my site”.

Most parameters for the command line have also an abbreviated name that you can use instead of the full parameter name.  For example, the following command sets the configuration database to use Server1_collab on Server1 and specifies the database user name and password to authenticate:

stsadm -o setconfigdb -connect -ds Server1 -dn Server1_collab -du User1 -dp password

The following table explains the commands and parameters from this example (as well as showing their full and abbreviated names):

Command or parameter

Definition

Full parameter name

Abbreviated parameter name

-o setconfigdb

Creates a connection between MOSS 2007 and a configuration database.

-operation

-o

-connect

Specifies that there is an existing configuration database to use.

-connect

 

-ds Server1

Specifies the server name that contains the database to use.

-databaseserver

-ds

-dn Server1_collab

Specifies the database name to use on that server.

-databasename

-dn

-du User1

Specifies  the user to authenticate.

-databaseuser

-du

-dp password

Specifies the password for the user.

-databasep

-dp

 

Ahh… one more thing… STSADM is not interactive!!!

STSADM is not an interactive tool. With STSADM, you type the operation and parameters all at once.  You will not be prompted to fill in missing parameters while the operation is running.  If a required parameter is missing, the operation fails, and you must type the operations and parameters again.

This behavior allows better flexibility for batching commands, because the tool does not prompt you for information after you have a s