Changing UI Version for Sharepoint using code
Visual Upgrade is a Site-level setting that selects which product version UI to use when displaying the Site. For example, one Site may use the 2007 UI while another could use the new 2010 UI. In our APIs, this setting is represented as an integer property on SPWeb called UIVersion.
The two valid values for this property are 3 (meaning SharePoint 2007) and 4 (meaning SharePoint 2010).
A common type of customization that needs to be aware of Visual Upgrade is ASP.NET markup. Two container controls are provided to make it easy to conditionally render markup based on the Site’s UI Version. Both controls conditionally render their contents based on whether the value in their UIVersion attribute matches the Site’s UI Version. The differences between the controls are :
1. UIVersionedContent: During the Init phase of the ASP.NET Page Lifecycle, if the value of the UIVersion attribute matches the current Site’s UI Version, UIVersionedContent will add its child controls to the ASP.NET control hierarchy. If the UIVersion attribute does not match the Site’s, the child controls are never added to the control hierarchy and no processing is done for them.
<sharepoint:uiversionedcontent uiversion=4">
<contenttemplateglt;
<!-- Content -->
</contenttemplateglt;
</sharepoint:uiversionedcontent>
2. VersionedPlaceHolder: During the PreRender phase of the ASP.NET Page Lifecycle, if the value of the UIVersion attribute does not match the Site’s UI Version, VersionedPlaceHolder will set its Visible property to false, thus hiding itself and all its children (i.e. Render never runs).
<sharepoint:versionedplaceholder uiversion==4">
<!-- Content -->
</sharepoint:versionedplaceholder>
Lstly, Control Pros and Cons
UIVersionedContent : No code from the child controls is ever run if the value of the UIVersion attribute doesn’t match the Site’s UI Version. It also doesn’t work for child controls that must be in the control hierarchy during the Page Lifecycle; for example, ContentPlaceHolders.
VersionedPlaceHolder : Works for ContentPlaceHolders and other controls that must be in the control hierarchy throughout the Page Lifecycle but, not as performant as UIVersionedContent since the logic in Init through PreRender in each of the child controls is run, even if the control won’t be shown on the page.
The two valid values for this property are 3 (meaning SharePoint 2007) and 4 (meaning SharePoint 2010).
A common type of customization that needs to be aware of Visual Upgrade is ASP.NET markup. Two container controls are provided to make it easy to conditionally render markup based on the Site’s UI Version. Both controls conditionally render their contents based on whether the value in their UIVersion attribute matches the Site’s UI Version. The differences between the controls are :
1. UIVersionedContent: During the Init phase of the ASP.NET Page Lifecycle, if the value of the UIVersion attribute matches the current Site’s UI Version, UIVersionedContent will add its child controls to the ASP.NET control hierarchy. If the UIVersion attribute does not match the Site’s, the child controls are never added to the control hierarchy and no processing is done for them.
<sharepoint:uiversionedcontent uiversion=4">
<contenttemplateglt;
<!-- Content -->
</contenttemplateglt;
</sharepoint:uiversionedcontent>
2. VersionedPlaceHolder: During the PreRender phase of the ASP.NET Page Lifecycle, if the value of the UIVersion attribute does not match the Site’s UI Version, VersionedPlaceHolder will set its Visible property to false, thus hiding itself and all its children (i.e. Render never runs).
<sharepoint:versionedplaceholder uiversion==4">
<!-- Content -->
</sharepoint:versionedplaceholder>
Lstly, Control Pros and Cons
UIVersionedContent : No code from the child controls is ever run if the value of the UIVersion attribute doesn’t match the Site’s UI Version. It also doesn’t work for child controls that must be in the control hierarchy during the Page Lifecycle; for example, ContentPlaceHolders.
VersionedPlaceHolder : Works for ContentPlaceHolders and other controls that must be in the control hierarchy throughout the Page Lifecycle but, not as performant as UIVersionedContent since the logic in Init through PreRender in each of the child controls is run, even if the control won’t be shown on the page.
0 comments:
Post a Comment