Posts Tagged ‘Master Pages’

Passing Parameters to Delegate Controls

Tuesday, March 13th, 2012

I have a requirement for a DelegateControl where I need the child candidate control to render a link that opens in a new window in certain instances of the DelegateControl and open the link in the same window otherwise. The design that made the most sense to me was to use the same code for the child control to compute and render the link in both circumstances and pass a boolean parameter, OpenLinkInNewWindow, to control the target of the link.

The reader might be wondering why I need a control just to render a link. For the purposes of this article, just assume that the control has some built-in intelligence to render a link that cannot otherwise be easily generated!

But how would I pass a parameter to the child control that the DelegateControl uses? Unfortunately, the DelegateControl itself does not have the ability to accept parameters. However, the Control element that defines child controls for a DelegateControl, within the elements.xml file for a feature, does have the ability to accept parameters. Perfect!

To define parameters for a control, one can setup property name/value pairs using the Property element, which is a child of the Control element. It’s pretty straightforward!

Say I have an application page, master page, etc. that needs to put the my fancy link-generating control in two separate places: one opens the link in a new window and one opens the link in the same window. In my page’s ASP.NET code, I have my two separate DelegateControls. I give each DelegateControl its own unique ControlId so that I can differentiate between the two.

With the above DelegateControls, I can use the first one wherever I need the link to open in a new window and the second wherever I need the link to open in the same window.

I would then define the following in the elements.xml file within the feature that adds the children to these DelegateControls.

Notice that I’m using the same control for both of the DelegateControls. I’m only changing the value of the OpenLinkInNewWindow parameter. This will use the same code in both DelegateControls to render the desired link. This allows me to use the LinkNewWindow DelegateControl wherever I want the link opened in a new window and the LinkSameWindow DelegateControl wherever I want the link opened in the same window.

Update: Adding parameters to custom controls
After sharing this article, I had a few colleagues suggest that I add a quick update around how to allow custom controls to accept parameters in the method described above. Parameters for a control can be created by using public properties defined on the control.

As long as the property is public, one can use the method outlined in this article to pass parameters when the control is used with a DelegateControl. If used in a more traditional context on an ASP.NET page, the public property could be used directly in the source code as follows.

There are several attributes that can decorate the public property to enhance its functionality as a property of the control. See the Attributes Applied to Public Properties section of the Metadata Attributes for Custom Server Controls article on MSDN for details.

Hiding the SharePoint 2010 Ribbon for Readers – A Proof of Concept

Saturday, February 5th, 2011

In SharePoint 2010 publishing sites, the ribbon is the new way of life for authors. However for readers, the ribbon provides very little, if any, functionality. A few days ago, I was asked about hiding this empty space by a client. Their current 2010 master page had the ribbon moved to a custom position on their publishing sites. They had also suppressed the breadcrumb/folder navigation in the ribbon; thus for a typical reader view, there was no ribbon contents that would be displayed. However, the space on the page where the ribbon would live for authors still remained as empty space!

We very well could have developed some server-side logic to determine the permissions of the user and hide that area completely based on that. Given infinite time and resources, I probably would have opted for that solution.

However, several of us were tasked with coming up with an easier and simpler solution to implement. One of the other consultants in the room at the time suggested a solution using JavaScript to hide the area if no contents was found (i.e. if the ribbon hadn’t rendered anything for the reader). I thought it was a great idea and immediately opened up an out-of-the-box publishing site in SharePoint Designer to tinker and develop a bit of JavaScript.

The goal of my JavaScript POC was to hide the entire div tag containing the SharePoint out-of-the-box ribbon control. I investigated and discovered that, in the nightandday.master file, the ribbon is contained in a div with the ID s4-ribbonrow. With that ID, I would be able to hide that div based on its rendered HTML contents. I figured, for this example, that the existence of the text “Browse” would be enough to determine whether or not the ribbon had rendered something or not.

To do this, I added JavaScript code to nightandday.master and it worked like a charm. Below is the relevant excerpt of nightandday.master:

<div id="s4-ribbonrow" ...>
    <!-- SharePoint out-of-the-box Ribbon Controls & Code goes here -->
<script type="text/javascript">
    var ribbonRow = document.getElementById("s4-ribbonrow");
    if(ribbonRow.innerHTML.indexOf("Browse") == -1)
    { = "none";

I should note that I only was able to spend about 30 minutes on this entire topic. Please treat the above code as a proof-of-concept and make sure to evaluate the impact or effectiveness of this code in your own environment before using it.