Welcome to EMC Consulting Blogs

So on my first look at the Managed References SDK for SharePoint 2010 contained in the technical preview (downloaded your copy from here) I noticed something very interesting the “Microsoft.SharePoint.PowerShell” namespace.

On closer inspection of the classes defined in the SDK it would appear SharePoint 2010 is going to use PowerShell as part of it's deployment process to perform certain administrative tasks such as install a feature.

Install-SPFeature FeatureId
Enable-SPFeature FeatureId -Url http://server/site/subsite

What's more it looks like you can write your own PowerShell cmdlets for use within a SharePoint deployment and all you have to do is get your cmdlet to inherit from “SPCmdlet”.

So all I can say is get learning PowerShell as it looks like it's coming to SharePoint in a big way. Which isn't a bad thing at all :-)

Well it’s been a while since I have done a blog entry so I thought I would ease myself back into them with a small post about how to debug a hidden feature.

As everyone knows in SharePoint you have the ability to make a feature hidden which means it doesn’t show up via the UI. This is useful if you don’t want users deactivating or activating a feature in the wrong site etc and making a mess of things. However, to debug these features I until quite recently use to switch the “hidden” attribute back to “false” so I could activate the feature via the UI and attached the debugger to the “w3wp” to see what gremlins were making my code go up in a cloud of smoke. However I learnt the other day about the “Debugger.Launch();” method which enables you to launch a debugger for your code and attach to the relevant process to enabling debugging (see http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.launch.aspx).

Now all I need to do when I want to debug my hidden feature is add “System.Diagnostics.Debugger.Launch();” at the start of the feature activate or deactivate. Additionally this same technique can be used to debug custom stsadm commands.

The other day while doing adding some validation in an ASP.NET application for some check boxes  I discovered a method I hadn't used before within the “ClientScriptManager” called “RegisterExpandoAttribute”. So you may well be asking yourself what does this rather strange sounding method do? Well it enables you to add new attributes onto a html element via JavaScript. OK so now you are probably asking yourself why should I care? Well that is a good question. First off this method enables you to attach server side information to html elements and enable that information to be used at the client by JavaScript. Secondly by attaching the information this way the html you produce remains XHTML compatible as the additional information is added by JavaScript. This means when you view the source for the page no custom attributes are present.

OK so what can you do with this? Well if you recall at the start of this entry I said I found this method while writing some code to validate check boxes. The way in which I used it was to attach additional attributes to a custom validator and then have the JavaScript function I defined for the client side validation use those additional bits of information to not only find the check boxes that were meant to be validated but highlight to the user which set of check boxes on the page failed to validate by adding to the containing element for the check boxes a CSS class that produced a nice red border. OK so the actual attributes I added were as follows:

1.CssClassOfParentElement: This is used in the JavaScript function to find a specific html element by a CSS class.
2.ErrorFieldCssClass: This is the name of the CSS class that should be applied in the event validation fails
3.IdOfControlToAddErrorStyleTo: This is the ID of the html element that should have the “ErrorFieldCssClass” applied.

Below is the JavaScript function I used to perform the validation on the client side.

function validateCheckBoxes(sender, args)
{
       var n = $("."+sender.CssClassOfParentElement+" > input:checked").length;
      
       var isValid = (n > 0);
       args.IsValid = isValid;
      
       if(!isValid)
       {
            $("#"+sender.IdOfControlToAddErrorStyleTo).addClass(sender.ErrorFieldCssClass);
       }
       else
       {
            $("#"+sender.IdOfControlToAddErrorStyleTo).removeClass(sender.ErrorFieldCssClass);
       }
      
}

The additional attributes were added as follows:

//Called from page load
private void RegisterClientSideValidationAttributesValidators()
{
    // Add attributes for programming types check boxes to custom validator
    Page.ClientScript.RegisterExpandoAttribute(cvProgrammingTypes.ID, "CssClassOfParentElement", "validateCssExampleProgramming");
    Page.ClientScript.RegisterExpandoAttribute(cvProgrammingTypes.ID, "ErrorFieldCssClass", "errorField");
    Page.ClientScript.RegisterExpandoAttribute(cvProgrammingTypes.ID, "IdOfControlToAddErrorStyleTo", cblProgrammingLan.ClientID);

    // Add attributes for colours check boxes to custom validator
    Page.ClientScript.RegisterExpandoAttribute(cvColours.ID, "CssClassOfParentElement", "validateCssExampleColours");
    Page.ClientScript.RegisterExpandoAttribute(cvColours.ID, "ErrorFieldCssClass", "errorField");
    Page.ClientScript.RegisterExpandoAttribute(cvColours.ID, "IdOfControlToAddErrorStyleTo", pnlColors.ClientID);           
}

I have included with this post a small test application that demonstrates how I set up the validation.

Enjoy!