October 2010
Current page:
 

Cross site collection navigation made easy

By: Vladi Gubler | Comments [11] | Category: Products | 10/4/2010

Hi All,

If you have a large SharePoint installation, you've probably already divided your data into several site collections and placed them in separate databases. The reason to do that are the built-in limitations of SharePoint, perfomance and backup restore functionality. Basically, it is really not a good idea to keep it all in one giant site collection as bad things will start happening pretty soon Undecided

But how you handle your navigation menu now? When everything was under a single site collection, SharePoint took care of it, whenever you added a site, it would appear under the navigation menu, no questions asked. Now it's a bit trickier, SharePoint has no native support for cross-site collection navigation (which sucks). You have a few options though:

  1. Create links between site collections manually - a pain in the lower rear end
  2. Create a custom web part to handle the navigation - crude, unnatural, prone to errors
  3. Use an XML navigation provider - not the most convenient solution, plus you need to update this file on all front-ends each time you add a site collection
  4. Missing some other similar bad solution...

All of these solution have major flaws and none of them provides a real security trimming for the menu, where each user only see what is permitted, which is very important for keeping everything safe and secure.

 

Well, there is a better way, our product, ECS (https://www.infowisesolutions.com/product.aspx?id=ECS) does just that and more. It seamlessly integrates into your web site to provide true security-trimmed cross site collection navigation, it will handle creation of new site collections and will even allow you to inherit permissions between different site collections. Your end users will be able to add new site collection without even knowing it! And obviously the product works with built-in cache, so the performance is excellent. You can even include site collection from a different farm altogether (the functionality is a bit reduced, but still you get the security trimming!)

 

Try it out now, the installation is a simple NEXT-NEXT-NEXT and you just activate the feature on a web application of your choosing. Not happy? Uninstall the product and everything gets back to normal immediately.

 

UPDATE: watch the demo now!

 

Custom Field View Rendering in SharePoint 2010

By: genady vaisman | Comments [6] | Category: Development | 10/3/2010
Hello,
ever tried to use custom field properties in rendering field content on a list view in sharepoint 2010? doesn't work..
so you google it (naturally) -
you hear about a magic way to deliver - CAMLRendering=TRUE, but hey - that doesn't work !!!
you go to msdn and find out that PropertySchema and RenderPattern are obsolete, but what is the way to do it in 2010, no one tells..
after a day of searching and wondering, i want to share my findings with you.
first of all, i still don't have a clue about how it suppose to be done in SharePoint 2010, but here's a working solution that will get you through meanwhile:
1. fldtypes_MyField.xml:
leave it as it was (or should be) for Moss 2007 - with rendering pattern and property schema, etc..
important: add the following properties AllowBaseTypeRendering & CAMLRendering !
for example:
<FieldTypes>
<FieldType>
<Field Name="TypeName">MyField</Field>
<Field Name="ParentType">Text</Field>
<Field Name="TypeDisplayName">TypeDisplayName;</Field>
<Field Name="TypeShortDescription">TypeDisplayName;</Field>
<Field Name="UserCreatable">TRUE</Field>
<Field Name="Sortable">TRUE</Field>
<Field Name="Filterable">TRUE</Field>
<Field Name="FieldTypeClass">MyField, MyField, Version=1.0.0.0, Culture=neutral, PublicKeyToken=...</Field>
<Field Name="FieldEditorUserControl">/_controltemplates/MyFieldFieldEditor.ascx</Field>
<Field Name="AllowBaseTypeRendering">TRUE</Field>
<Field Name="CAMLRendering">TRUE</Field>
<PropertySchema>
<Fields>
<Field Hidden="TRUE" Name="MyCustomProperty" DisplayName="MyCustomProperty" Type="Text">
</Field>
</Fields>
<Fields></Fields>
</PropertySchema>
<RenderPattern Name="HeaderPattern">
<HTML>
<![CDATA[
<script type="text/javascript" language="javascript" src="/_layouts/MyFieldHelper.js"></script>
]]>
</HTML>
<!-- copy the rest of the header pattern of base field -->
</RenderPattern>
<RenderPattern Name="DisplayPattern">
<Switch>
<Expr>
<Property Select="MyCustomProperty" HTMLEncode="TRUE"/>
</Expr>
<Case Value="">
<Column HTMLEncode="TRUE"/>
</Case>
<Default>
<Property Select="MyCustomProperty" HTMLEncode="TRUE"/>
<!-- call js function inside HTML element, like in Moss -->
</Default>
</Switch>

</RenderPattern>
</FieldType>
</FieldTypes>
2. fldtypes_MyField.xsl:
this one is new for SharePoint 2010, and it goes to Templates\Layouts\Xsl
in order to your js calls will be evaluated properly, you need these templates:
<xsl:stylesheet xmlns:x="http://www.w3.org/2001/XMLSchema"
xmlns:d="http://schemas.microsoft.com/sharepoint/dsp"
version="1.0"
exclude-result-prefixes="xsl msxsl ddwrt"
xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime"
xmlns:asp="http://schemas.microsoft.com/ASPNET/20"
xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
xmlns:SharePoint="Microsoft.SharePoint.WebControls"
xmlns:ddwrt2="urn:frontpage:internal">
<xsl:template match="FieldRef[@FieldType='MyField']" mode="header">
<th class="ms-vh2" nowrap="nowrap" scope="col" onmouseover="OnChildColumn(this)">
<script language="Javascript" type="text/javascript" src="/_layouts/MyFieldHelper.js" />
<xsl:call-template name="dvt_headerfield">
<xsl:with-param name="fieldname">
<xsl:value-of select="@Name" />
</xsl:with-param>
<xsl:with-param name="fieldtitle">
<xsl:value-of select="@DisplayName" />
</xsl:with-param>
<xsl:with-param name="displayname">
<xsl:value-of select="@DisplayName" />
</xsl:with-param>
<xsl:with-param name="fieldtype">
<xsl:value-of select="@FieldType" />
</xsl:with-param>
</xsl:call-template>
</th>
</xsl:template>
<xsl:template match="FieldRef[@FieldType='MyField']" mode="body">
<xsl:param name="thisNode" select="." />
<xsl:value-of select="$thisNode/@*[name()=current()/@Name]" disable-output-escaping="yes" />
</xsl:template>
</xsl:stylesheet>
all other stuff - MyField, MyFieldEditor, Field Rendering Control, custom property storage work around all remains the same.
?
?happy coding,
?Genady
 

Error using Exchange WebDAV from code

By: Vladi Gubler | Comments [1] | Category: Development | 10/3/2010

Hi,

Adding Exchange interoperability to our Event Calendar web part we stumbled upon a weird errors, everything was written correctly, it was supposed to work, it worked in the samples we used as a basis for our own code, but still, no go. Took me a while to realize that the order of adding the header to the web request was important, you need to specify the header just after creating the WebRequest object, and then it's going to work smoothly.