Archive for December 2009
What’s that supposed to mean? That’s what went through my head when I saw a new link which had appeared on the List Settings page (listedit.aspx) in SharePoint 2010.
When I clicked the link, I was directed to a page where I could manage the available views per “location”.
The word “location” can have many different meanings. My initial thought was that it was referring to folders inside the list and that this page is used to configure which views are available per folder.
This turned out to be correct. I added a folder to the list and was able to make my custom view appear on there, whilst hiding it from the root of the list.
Is that all? Why call it locations when you mean folders? Well, because it does not only apply to folders!
You can configure available views for ANY NODE in the “Metadata navigation”. As a result, In addition to views per folder – depending on how you set up your Metadata navigation for your list – you can:
- Define views that are available only on items of a particular Content Type (my favourite, demonstrated below)
- Define views that are available only on items that have a particular value for a field of type single-value choice.
- Define views that are available only on items that have a particular term applied to it on a field of type Managed metadata.
Let me demonstrate how to make our “Books Grouped by Author” view available only to our Book content type in our Products list, whilst hiding it for all other type of products in the list.
Below is a summary of all the steps. I will only discuss the last two steps where we configure Metadata navigation and the Per-location view settings, as this what this article is all about.
- Create custom list Products
- Create content types:
- Book (Title, Price, Author)
- Movie (Title, Price)
- Music Album (Title, Price, Artist)
- Configure list to allow management of Content Types
- Associate Book, Movie and Music Album with list and delete Item Content Type
- Populate list with items for each Content Type
- Create view Books Grouped by Author
- Configure Metadata navigation
- Configure Per-location view settings
Once we have successfully performed steps 1 to 6, we need to bring up the Metadata navigation settings screen for our list. The link to this page can be found on the List Settings page. In the Configure Metadata Hierarchies section, we need to select the “Content Type” item from the list on the left and move it to the right and press OK
As a result, we should now get a hierarchical navigation control on the left of our list.
Once that’s done, we need to bring up our Configure per-location view settings page. The link to this page can also be found on the List Settings page. On the left, there is a hierarchical control labelled “Location to Configure”. We need to use this to select the node (or Location if you like) to which we will be applying the configuration defined on the right. We start with the root node, which is selected by default. We don’t want our grouped view to be available at the root, so we select it in the “Views available at this location” list and move it to the “Views hidden from this location” list and press Apply. Next, we need to expand the “Content Type” node in the tree on the left and select Book. By default it is configured to inherit its settings from its parent, which it not what we want. Set this to No, and move the grouped view to the “Views available at this location” list. While we are at it, let’s move the All Items view to the “Views hidden from this location” list, so that our grouped view becomes the default view for the Book Content Type, and press OK.
Navigate to the list. When selecting Book in the Metadata Navigation on the left, the grouped view should now show instead of the All Items view. Note that the Book Content Type node in the metadata navigation, is also the ONLY location where our grouped view is available.
On a final note, I noticed that the Per-location view settings link does not appear on the List Settings page when the list is contained in a Blank Site. I performed the actions above on a Team Site. Presumably certain Features needs to be activated to enable this functionality, however I currently don’t know which one. Also, I am not sure how much of this functionality depends on SharePoint Server 2010 and whether it will work on a SharePoint Foundation installation.
If you are into developing SharePoint solutions using jQuery, you should really have a look at the following GREAT CodePlex projects. Both projects have been developed by real experts in the SharePoint & jQuery field
This is a jQuery library which abstracts SharePoint’s Web Services and makes them easier to use. It also includes functions which use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.
As announced before, I have been working an open source project that visualizes the data in the Developer Dashboard in SharePoint 2010.
The good news is that SharePoint Developer Dashboard Visualizer is now up on CodePlex.
SharePoint 2010 Developer Dashboard Visualizer is a jQuery-based solution that extends the Developer Dashboard by plotting an interactive diagram with data from the Developer Dashboard, giving you an **instant** insight into where the bottlenecks are in your code.
The installer is just a WSP so it’s a quick and easy install!
Finally, a big thank you goes out to Bil Simser for being the first person to post a review for SharePoint Developer Dashboard Visualizer online.
The problem I see with Business Connectivity Services is the lack of context available when writing your custom code to retrieve and update data. As a result, custom BCS implementations are not very reusable because the lack of configuration options per External List.
Let’s look at an example.
ACME Ltd, an ISV focusing on selling SharePoint products, wants to develop and sell a BCS solution that allows customers to create External Lists based on data that resides in ANOTHER SharePoint site collection. In a nutshell, the External List will contain a “virtual” list item for each site in the target site collection. Now how does the BCS code know where this target site collection is? You could hardcode the url, or you could store the url in the appSettings in the web.config for your web app. These are both solutions that will give you headaches when you need more than one instance of this External List, each using the same BCS code, but retrieving data from different target site collections.
When I created a new Business Data Connectivity Model in Visual Studio 2010 for the first time and I looked at the code that was initially generated (Entity1Service.cs), I was surprised that there seemed to be no way to derive any of the following in code:
- SPWeb instance or url of the site that contains the External List we are trying to load data for.
- Name (or ID) of the External List we are trying to load data for. This, together with an SPWeb, would allow you to read per-list configuration data from SPList.RootFolder.Properties
- Some string containing configuration data that applies to our BCS Entity to External List association. Something similar exists for EventReceivers and Workflow, so why does it not exist for BCS?
I would be very interested to hear people’s thoughts on this subject.