So when enumerating the SPWebs within a SPFarm to build a strongly typed SPWeb collection for whatever purpose your enumeration might look like this:
public static List WebsPreppedForIteration()
var collection = new List();
foreach (SPSite x in SPFarm.Local.Services.OfType().SelectMany
(svc => ((svc).WebApplications.Where
(webApp => !webApp.Properties.ContainsKey(“Microsoft.Office.Server.SharedResourceProvider”)).SelectMany
(webApp => webApp.Sites.Cast()))).Where
(x => !Equals(x.RootWeb.Title, “Central Administration”)))
I saw this in a code review today. The part I am wondering about is the SPWebApplication property bag to query the key for WCAM as opposed to do a clunky string SPWeb.Title comparison. Putting the keys out to standard output hasn’t yielded anything particularly evident, and I’m getting frustrated with the under-the-hood, unnecessary foreach loop with a fancy shirt on (the second LINQ query against the Title property(,
Does anyone know the key for WCAM?
There are several design considerations when using SharePoint 2010 folders when designing the information architecture. Importantly and obviously, plan for the number of items that will be organized in each folder. Those items can be moved either manually or it can be automated. INcorporated features include the metadata navigation so that the amounts of items in folders don’t have such strict limits. Use metadata navigation and folder navigation so that the folders are able to be used for policies and retention. This is in addition to the folders being used for organization. Organization of content in folders so that they can be easily navigated as well as combined with other available options for the simplification of navigation. The content organizer will automatically move the documents into folders base on the metadata. They can also be enabled with the option for creating various sub folders after the limit in a given folder has been reached. Organize items into folder so that only the list view threshold at the root of the folder is there when you use the Open with Explorer. In order to retrieve content in list views there is metadata navigation and indexing that you can use in addition to the folders.
Organizing the content into folders needs to be done carefully. There are three main methods used for achieving this:
Organize logically This can be based on month, year, or other types of data like responsible division. Or other stuff. Whatever’s clever.
Metadata this allows for documents to be routed to the correct folder. This allows for the ability to limit the amount of items in a single folder. Then sub folders are also used when more space needs to be added.
Topic or category Many users like the idea of being able to find things by topic or category. They are used to such navigation so it seems natural. This is sorta like the first point.
Various improvements for SharePoint Server 2010 allow you to have a flexible use of the folders. You will be less dependent on various performance considerations as well. When you have managed metadata and navigation you can easily filter the data through the folders. This makes it possible for you to organize your information for administrative control. This includes your permissions and policies. You won’t be relying only on the end user navigation.
When the content organizer feature is automatically moved into the folders by content, the metadata users don’t need to decide where to place the content. The content organizer also allows for the creation of new folders after a limit of one has been reached. When you use “Open with Explorer” you have to remember that it doesn’t work with large lists of items if they aren’t organized in folders with fewer items than the list view threshold.
When it comes to folder based view and metadata based views, keep in mind that they are very similar when it comes to how they perform. With a logical user experience then it is sensible to rely on folders to divide your content. With metadata navigation though there are queries that allow for all of the items to be returned outside of the folders.
* Folders do have better performance at smaller sizes of lists.*
The FullTextSqlQuery class is really nice for building readable query statements, all in familiar SQL syntax. While it’s a lot easier to use when querying data, the returned content is limited to that which has been indexed by SharePoint.
This is something to keep in mind, the indexing part. Consider the following code snippet, delivered as a generic static method:
RunQuery(“SELECT FileExtension, ContentClass, IsDocument, title, path, author from scope() “);
public static RunQuery(string queryText)
FullTextSqlQuery query = new FullTextSqlQuery(SPContext.Current.Site);
query.ResultTypes = ResultType.RelevantResults;
query.QueryText = queryText;
ResultTableCollection resultCollection = query.Execute();
DataTable resultDataTable = new DataTable();
ResultTable resultTable = resultCollection[ResultType.RelevantResults];
While running such code, you may encounter a problem where the wrong site collections are returning data. It may crop up in the form of a particular site collection being always used, or a weird permutation of site collections. If this problem occurs, there are generally two causes of the problem.
1) Ensure you are referencing Microsoft.Office.Server.Search.Query.FullTextSqlQuery and not Microsoft.SharePoint.Search.Query.FullTextSqlQuery
2) Ensure in Central Administration / Site Settings / Search And Offline Availability /Indexing Site Content the content is being indexed.