SharePoint Web Parts: Wrapping .NET user Controls for Editors and End Users

Recently, I worked with a new functionality for a client that had SharePoint managing content alongside some .NET features. One might say that these two Microsoft brothers should work smoothly together, but sometimes it can be challenging. We wrote about using SharePoint from a WCM perspective recently and that post outlines some of these challenges. Nonetheless, here are some tips based on my involvement that might make your life easier when it comes to dealing with SharePoint and .NET.

First, let’s set up the scenario. We had a person that had experience in SharePoint development on our team, who made sure best practices were followed. For instance, some of the HTML markup was implemented in User Controls. Indeed, as many have recommended, this made the development of functionality easy since we were able to reuse the controls created for the new functionality (with some modifications). Also, deployments of .NET changes to SharePoint were handled by WSPBuilder. Using WSPBuilder, WSP deploy packages were very straightforward. On the other hand, debugging had some issues, but nothing that remote debugger couldn’t handle.

Second, we worked with ASP.NET Web Controls and SharePoint. In this scenario, we had the .NET controls wrapped by “Web Parts”. Though there are general guidelines to be followed when developing User Controls targeted for a SharePoint environment, this was the tricky part for me. I found out that it is a developer’s responsibility to determine if the control is being viewed in Design Mode or Edit Mode in SharePoint. Why? Let me explain by example. If a User Control is expected to be fetching data on page load, we want to make sure that this does not happen in Edit/Design Mode, otherwise it might break. The same applies to disabling Asp.Net validators, otherwise they will auto fire in SharePoint’s Edit/Design mode. There are some options regarding on how to handle ASP.NET validators on SharePoint. Part of this problem can be fixed by detecting SharePoint’s mode at a Page Layout level, Web Part level or Control level. This post explains how to detect SharePoint’s mode at each level. As explained in that post, we had a similar code that detected the current mode and handled validation.

    protected override void OnPreRender(EventArgs e){
        base.OnPreRender(e);
        if (SPWebPartManager.GetCurrentWebPartManager(Page).DisplayMode != WebPartManager.BrowseDisplayMode)
        {
            foreach (object validator in Page.Validators)
            {
                if (validator is BaseValidator)
                {
                    ((BaseValidator)validator).Enabled = false;
                }
            }
        }
    }

Still, we had the validators firing in Edit/Design Mode. We tried some of the solutions suggested by our SharePoint team member who already encountered this problem:

1. Set the property “Causes Validation” to false in all the inner controls that made a "Postback".
2. The controls that are going to be validated and the validation controls attached to them should have a validation group with a unique name within the “Web Part”. The downside to this fix is that you will have to manually validate the groups.This article explains how this can be achieved.

Finally, the solution that did the trick was a JavaScript hack that pre-filled the fields that had a validation control in Edit Mode. SharePoint’s Stack Exchange shows on how you can detect the SharePoint mode via JavaScript. Nevertheless, the solution turned out to be much simpler.  For us, we had to add on the Publish Layout Page the following code:

<%-- Fixes the login control validators firing in edit mode --%>
    <PublishingWebControls:EditModePanel runat="server" id="EditModePanelLogin" Visible="false">
           <script type="text/javascript">
               $(document).ready(function () {
                   $('.formRegUsername').val('test');
                   $('.formRegPassword').val('test');
               });
        </script>
    </PublishingWebControls:EditModePanel>

In the end, there are many different opinions when it comes to SharePoint development. Moreover, there are many best practices and resources available on line, including this great blog on SharePoint Development. For me, it was my first experience working with SharePoint and I found it to be quite enjoyable.