SharePoint world of ECM and Information Management : Web Parts

Connect to database directly without BDC

Michael — Tue, 21 Apr 2009 14:26:05 GMT

Lightning Tools released the Web Part, which allows you to connect to database directly, without using BDC. Having direct access to tables, stored procedures is that functionality with WSS and MOSS Standard didn’t have and a lot client suffered from that, developed their own solutions.

Now LT Data Viewer Web Part provides you all necessary information

The Lightning Tools Data Viewer Web Part can save you time and money as it stops the need for developers to write custom code and allows your end users to easily display and format the data they need to see.

The LTDVWP provides the following benefits:

1. No need for SharePoint Designer. The LTDVWP is configured within the browser.
2. Allows for Integrated Security or provided Username and Password
3. Allows for connection to SQL, Oracle and Access (accdb & mdb) via the configuration of properties. (No need for Connection Strings)
4. Connect directly to Tables/Views and Stored Procedures
5. Supports Aggregate Functions such as Count, Min, Max, and Sum
6. Allows for Conditional Formatting on Cells or Rows
7. Filtering of data
8. Caching of Data
9. Update, Delete, and Insertion of Data
10. Web Part Connections

SharePoint Tip #27. Do you know “How to make Web Part zone WCAG compliant”?

Michael — Fri, 20 Mar 2009 06:07:49 GMT

SharePoint provides you a nice ASP.NET model of Web Parts functionality. But when we are building the internet faced public sites and trying to apply Web Content Accessibility Guidelines (WCAG) on Web Part Zones it come back and bite us. The major problem is that Web Part zone is not WCAG compliant.

There are several ways to achieve desired behaviour

use “Accessibility Kit for SharePoint”. It seems to be very logical step to consider :) There are 25(!) different adapters, which have to address accessibility of Web Parts, but harsh reality is that none of them address Web Parts Zones compliance. Yep, it’s not a joke :) So, cross out this point
Use *custom* adapter on the top of WebPartZone to render content with <DIV> tag. Unfortunately SharePoint integrated a lot if JavaScripts to their web parts zones, that current approach breaks drag-n-drop functionality of Web Parts. (I reckon that’s why AKT didn’t address this issue)

In these days using custom adapters is the only way to achieve WCAG for Web Parts Zone. It won’t work for the intranet sites, due to broken drag-n-drop functionality, but for public sites it has not disadvantages, because you usually don’t allow users to change layout of public sites.

You can find custom adapter for the Web Parts zone there. Thanks to eigilm for this code.

Have anything to add?! Send your tips to be published via this form

Why Content Query Web Part (CQWP) doesn’t return all results.

Michael — Wed, 24 Dec 2008 11:59:55 GMT

I’ve seen several cases, when people use CQWP and surprises when it doesn’t return all items in standard mode and returns all necessary items in “edit” mode. I find this topic is not being documented enough anywhere.

So, CQWP ignores following items from your queried data:

Items are checked-out
Items are not published and not-approved

Those scenarios are “behaviour by design”, and I found such behaviour logical. User’s are working on their items, and work in progress – you shouldn’t show such items

Workaround: set “UseCache” property to “false”.

Cite from SharePoint team:

“You are only seeing your items in edit mode because the caching infrastructure of the CQWP does not cache checked-out items of individual users and we disable cache in edit mode. You can disable caching on your Web Part by setting the "UseCache" property to false”

So, my recommendation is to revise your approach to return published and checked-in stuff only.

Mirror: Why Content Query Web Part (CQWP) doesn’t return all results.

Deploying SharePoint Web Parts as a part of PageLayouts in MOSS 2007

Michael — Fri, 08 Aug 2008 17:45:00 GMT

Web Parts are an important and everywhere used part of SharePoint. Web Parts are documented pretty good and there are several sources describing as just ASP.NET WebParts (Darren Neimke book) and some resources about Web Parts in SharePoint as well. But in reality SharePoint WebPart specific stuff is not properly documented, and in this post I’d like to publish some tips regarding Web Parts in SharePoint

General Info

Not all Web Parts are inherited from System.Web.UI.WebControls.WebParts.WebPart class. Some of them comes from Microsoft.SharePoint.WebPartPages.WebPart, which is inherited from the System.Web.UI.WebControls.WebParts.WebPart now. When you develop your own Web Parts, in mostly cases you need to inherit from System.Web WebPart class

Finding the connections

For some tasks you might handle the Web Part connection/disconnection programmatically. For example, connect your Web Part via code or via Page Layouts. To do this you need to know the Consumer and Provider names. It’s not the problem for your Web Parts, but how to find the Provider name for the out-of-the-box Web Parts?! For this you need to use Reflector.

First, to know the class name of SharePoint Web Part you need just put any Web Part to the page and export it to XML. In that XML you will find the assembly and class name. After that open that assembly in Reflector and navigates to the class you need to get Provider name. Scrutinize that Web Part class to find the connections and name of Provider connection. Connection may be not exactly in that class, but in one of the base classes.

For example for Page Filter Web Parts the Provider name is “ITransformableFilterValues”

Deploying Web Parts with connections

If you deploy you pages and want to have Web Parts being already connected for each new page user creates, then you need to connect Web Part via XML description inside Page Layout.

Connection consists from 3 parts:

Consumer ID and Name –which you know, because usually it’s you own custom Web Parts
Provider ID and Name – I described above how to extract that name
Name of the parameter you select from dialog box when connect Web Parts manually.

So, let’s start:

Put any Web Parts to your Page Layout (I use SharePoint Designer for this, because it simplify my work), save page and navigate to the code.
In code find the <WebPartPages:WebPartZone> section, and there you will find you Web Parts markup tagged with <Components: prefix.
Find the ProviderID attribute of the Web Parts you want to connect and remember values . These values will be used when we create the connection between Web Parts.
Open your page in browser to verify it works.
Connect Web Parts manually, and save the name of the parameter which is shown in the popup dialog box when you connect Web Parts
Remove connections between Web Parts, and return back to SharePoint designer
Open the Page Layout code and navigate to the very beginning of document. Try to find the following section “<WebPartPages:SPProxyWebPartManager”. If you don’t have this section you can miss the following step
Add the <WebPartPages:SPProxyWebPartManager runat="server" ID="ProxyWebPartManager"> section inside “PlaceHolderMain” content holder
Now, we are ready to create connections. Add the following codesnippet inside SPProxyWebPartManager

<SPWebPartConnections>
           <WebPartPages:SPWebPartConnection ID="g_myConnectionName"
               ConsumerConnectionPointID="IFilterValues" ConsumerID="WebPartA"
               ProviderConnectionPointID="ITransformableFilterValues" ProviderID="WebPartB">
               <WebPartPages:TransformableFilterValuesToFilterValuesTransformer MappedConsumerParameterName="Parameter">
               </WebPartPages:TransformableFilterValuesToFilterValuesTransformer>
           </WebPartPages:SPWebPartConnection>
</SPWebPartConnections>

Let’s review the “blue” selections, because it’s where connection magic happens

- g_myConnectionName is the name of current connection, can be any name
- IFilterValues – Consumer interface name of Web Part which accept connection
- WebPartA – consumer Web Part ID from the WebPartZone section we found and remembered previously
- ITransformableFilterValues – Provider interface name of Web Part which provides connection (in this sample I used Page Filter web parts and they have such provider name. Refer to the “Finding the connections” section where I described how to extract the names
- WebPartB – provider Web Part ID from the WebPartZone section we found and remembered previously
- Parameter – the name from the connection dialog box where you select the parameter

10. Save the page layout. Go to SharePoint and create the new page based on that page layout. After page will be created you can find that your Web Parts are already connected. Job done!

Take into account, that you can’t change Web Parts connection for pages created for the Page Layouts with predefined Web Part connections.

Mirror: Deploying SharePoint Web Parts as a part of PageLayouts in MOSS 2007

Subclassing Content Query Web Part to override CAML query

Michael — Wed, 28 May 2008 13:37:27 GMT

The Content Query Web Part (CQWP) in MOSS is one of the popular out-of-the-box Publishing components which is used in content management sites, allowing you to get results from different sources.

But sometimes out of the box functionality is not enough to meet your requirements, and you need to customize CQWP. There are several resources describing how to do this - 1, 2, 3, 4

The most important features which are missed in CQWP are:

overriding query to use custom CAML
enabling web-part connections

To implement these functionality you need to subclass ContentByQueryWebPart class and override several methods.

Below I will describe what exactly need to be done to achieve desired behaviour.

Query Override

To have custom CAML query in your Web part you need to override CreateChildControls base method. You can find samples how to do this in the references above, but it's done so implicitly, that you can easily spend hours to find out why you code doesn't work and gives you different errors

The crucial part is in the way sending the query to the base class within overrided CreateChildControls

   1: protected override void CreateChildControls()   2: {   3:     this.QueryOverride = customQueryString;   4:     5:     base.CreateChildControls();   6:     7:     QueryOverride = string.Empty;   8:     9:     CommonViewFields = string.Empty;  10: }

First, you need to set your custom query to the "this.QueryOverride" to inform base class about query - line 3

Second, call base CreateChildControls() allowing your query being executed - line 5

Third and last - CLEAN query and view fields properties - line 7,9. Without this step you will get errors when open your Web Part in edit mode

Enabling Connection

The Content Query WP doesn't accept any connections by default. You need to implement this too. Everything you need to to is just add ConnectionConsumer attribute. But trick in setting the right attribute which is used in Parameter dialog box, when you connect two web-parts.

   1: [ConnectionConsumer("Another WebPart", "IFilterValues", AllowsMultipleConnections = true)]   2: public void SetConnectionInterface(IFilterValues filterProvider)   3: {   4:     if (filterProvider != null)   5:     {   6:         // save provider with values   7:         providerValues = filterProvider.ParameterValues;   8:         _filterProviders.Add(filterProvider);  // variable declaration is List<IFilterValues> _filterProviders = new List<IFilterValues>();   9:         List<ConsumerParameter> parameters = new List<ConsumerParameter>();  10:           11:         // add params  12:         parameters.Add(new ConsumerParameter("param1",  13:                 ConsumerParameterCapabilities.SupportsSingleValue |  14:                 ConsumerParameterCapabilities.SupportsEmptyValue));  15:         parameters.Add(new ConsumerParameter("param2",  16:                 ConsumerParameterCapabilities.SupportsMultipleValues |  17:                 ConsumerParameterCapabilities.SupportsAllValue |  18:                 ConsumerParameterCapabilities.SupportsEmptyValue));  19:    20:         filterProvider.SetConsumerParameters(new ReadOnlyCollection<ConsumerParameter>(parameters));  21:    22:         }  23: }

Method name can be any, but pay attention which provider you are using . WebPart providers send data via different provider interfaces, for example when you are working with Filtering web parts (like "Current User Filter" web part) then you need to "listen" your incoming connections via IFilterValues (thx Mutaz for this findings), for other WB it could be IWebPartField or IWebPartRow.

If you are expecting to get data from WP via unsupported provider you connection link will be dimmed

Practical Sample

@d2design kindly asked to provide practical sample, for example how to use current user as a keyword :)

Actually, it's good example which shows how use both features I described.

To do this you need to have:

ShareServices (SSP) with UserProfile, where current userName is stored
"Current User Filter" WebPart, to get the userName from SSP. It returns you logged user name by default (not necessary actually, as well as SSP, because you could resolve you user name via standard asp.net User class when construct custom query)
Enable WebPart connections as I described above. You need to use IFilterValue interface for "Current User Filter" and store your incoming user name in variable.
Override query to include your userName in resulted custom query.

TIPS:

When you are quering content which is not published and approved (like pages) you wont be able to see that content on the page in final view. You data will be available in page edit mode only, because they are treated as "draft" data.
<OrderBy>CAML tag is not parsed by CQWP, you need to remove it from your query and set the related order field of CQWP class

Mirror: Subclassing Content Query Web Part to override CAML query