The Problem Described

Take a look at the ASP.NET MVC 3 default route found in the Global.asax.cs file:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{id}", // URL with parameters
        new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
    );
}

This default route will basically allow you access to a resource using the basic URL convention that may look something this: http://localhost/products/edit/1 . However, the default RavenDB auto generated document identifier for the product document ends up looking something like this: products/1. (More information about the RavenDB document identifiers one of the documentation pages. ) So the URL to access that product resource for editing would really have to look like this: http://localhost/products/edit/products/1. Well that doesn’t work for two reasons:

1. The default route will not be matched so the URL will not be routed the correct controller action.
2. The URL is not SEO friendly.

Typically, this can be solved by using a custom route that access this resource by a natural key where the URL would probably end up looking like this: http://localhost/products/product-name/edit. This makes the URL SEO friendly, easy to read, and easy to route. However, there are some situations where the document identifier makes sense and I will continue this post on the assumption that this is the case.

The blog post mentioned above presents two solutions:

• Solution 1 – Change the identity parts separator convention for the RavenDB document store.
• Solution 2 – Modify the ASP.NET default route

Issues with Solution 1

Let’s look at the first solution. The suggestion is to change the identity separator convention from a slash (/) to a dash (-). The convention is really easy to change during the initialization of the document store object.

documentStore = new DocumentStore { Url = "http://localhost:8080/" };
documentStore.Initialize();
documentStore.Conventions.IdentityPartsSeparator = "-";

This makes RavenDB generate document identifiers that now look like: products-1. Now we can generate a URL that will match the default route and may look like: http://localhost/products/edit/products-1. I still find some issues this this. Namely, the URL is still not really SEO friendly and not really human readable. I don’t like the idea of exposing an identifier that was forced on me by RavenDB since it essentially has coupled my URL to the RavenDB identifier convention. It just doesn’t feel right.

Issues with Solution 2

This solution suggests the change of the default route to something like:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{*id}", // URL with parameters
        new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
    );
}

This will allow route to match a URL that looked like the first one: http://localhost/products/edit/products/1. I don’t like this either. While it does allow the default route to match and do its job. The URL is just ugly. It also clobbers the id making the route also match something like this: http://localhost/products/edit/products/more-junk/1. Obviously this is not SEO friendly or human readable. Again, it just doesn’t feel right.

Another Option

After some digging and learning about more about the document identity field, identity type converters, custom identifiers with the document key generator convention, I realized there was a pretty simple alternative to the two options above. But to see it and to understand the simplicity, you have to look at the source of the problem.

The reason that MVC routes are choking on the preconfigured RavenDB document identity convention is because our models included a string based identity property. I realized I had done this on purpose to ease the mapping of the RavenDB document identifier and my object identifier. Take a look at my product object definition:

public class Product
{
    public string Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public string ImageUrl { get; set; }
    public decimal Price { get; set; }
}

The shopping cart identifier is a string. Why would it be a string? It could have been an integer or a Guid or something else. It could have even been a natural key of some sort. Or even a compound key. It doesn’t have to be a string. Taking another look at the  IDocumentSession interface we can see we have four load methods available.

namespace Raven.Client
{
  public interface IDocumentSession : IDisposable
  {
    ISyncAdvancedSessionOperation Advanced { get; }
    void Delete<T>(T entity);
    T Load<T>(string id);
    T[] Load<T>(params string[] ids);
    T[] Load<T>(IEnumerable<string> ids);
    T Load<T>(ValueType id);
    IRavenQueryable<T> Query<T>(string indexName);
    IRavenQueryable<T> Query<T>();
    IRavenQueryable<T> Query<T, TIndexCreator>() where TIndexCreator : AbstractIndexCreationTask, new();
    ILoaderWithInclude<object> Include(string path);
    ILoaderWithInclude<T> Include<T>(Expression<Func<T, object>> path);
    void SaveChanges();
    void Store(object entity, Guid etag);
    void Store(object entity, Guid etag, string id);
    void Store(object entity);
    void Store(object entity, string id);
  }
}

After thinking about the difference between the method that accepts a string identifier and the one that accepts a value type identifier, I realized that all I had to do was change my identifier type from a string to a value type and I’m done. No fancy mapping or parsing the document identifier from RavenDB to the web browser and back. No changes to the default MVC route. No changes to the default identity separator convention. It just worked. My URLs are SEO friendly and more readable.

All I had to do was change the object identifier type.

public class Product
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public string ImageUrl { get; set; }
    public decimal Price { get; set; }
}

That was easy.

Of course this doesn’t solve everything. What if I really do need a string based identifier? This will probably require tweaking the behavior of the RavenDB client. I also don’t have an answer for compound keys and other natural keys which may not be a value type. Some of these may require more thought from both the RavenDB side and the MVC side of my project. But that is another problem to think about some other time.

1. Remove the MicrosoftMvc*.js AJAX and validation scripts.
2. Update NuGet packages… I do things a little differently here. I completely remove the EntityFramework package (I may add it or another ORM back in later, but that ends up usually in a persistence specific project and it is usually a micro ORM). I also remove jQuery Visual Studio 2010 Intellisense package since the contents are bundled with the updated the other jQuery packages anyway. I remove the jQuery UI package (and add it back when I need it). Update the remaining jQuery and Modernizr packages.
3. Create my own JavaScripts directory to avoid overwrites when updating or installing other JavaScript based packages.
4. Love this tip! Who doesn’t like intellisense?
5. Already did this in step 2.
6. I’m not the sharpest tool in the shed when it comes to CSS. But this tip sounds like a good idea. Wonder if there is a NuGet package for Eric Meyer’s reset.css file?
7. I skip this step. In my opinion, the only models in my MVC project are view models anyway. So I leave the Models folder in my MVC project alone. If my project requires business models, they get placed in a business logic project. If I have persistence models, they get placed in my persistence project.
8. Another area where I am not the sharpest tool in the shed. But I do like fast loading pages, so I am going to try this tip out and put all the JavaScript files that I can at the bottom. Just remember that some do need to go at the top.
9. And yet another tip that I haven’t tried, but plan.

As a recap, tips 1, 3, and 4 make perfect sense. Tip 2 also makes sense, but I tweak it to fit my needs and I suggest you do to. I glaze over tip 5 and skip tip 7 because it was either previously addressed or doesn’t fit my needs. Tips 6, 8, and 9 sound like good ideas and I need to try them out.

• Nerdi - A collection of web development resources. From toolkits, to frameworks, to documentation, and all sorts of goodness.
• Font Awesome - An iconic font.
• kuler - A color scheme generator.

More stuff for me to play with. It’s times like these I wish I had a more innate ability to work with colors and design. It reminds me of the time I attempted to use another color scheme generator and quickly learned that the tool alone would not help my bad design. It only color coordinated it.

Intoduction to SharePoint 2010 for Developers

This webinar is also available on the DevExpress Channel.

SharePoint 2010 Data Access

This webinar is also available on the DevExpress Channel.

Andrew was also kind enough to publish a wrap-up blog post with links to additional references.

Real World SharePoint 2010

I never got around to buying Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs (Programmer to Programmer) but, I did get a chance to glance through the book and there was some great material. Today, I found out that Real World SharePoint 2010: Indispensable Experiences from 22 MVPs is going to be available on November 23, 2010.

Of course, I just pre-ordered my copy.

In a MOSS 2007 installation we have a site with a wiki library. The wiki library has been customized a bit with event handlers to do some fancy automatic permission assignments to individual wiki pages and prevent some users from approving wiki pages that they are not allowed to. This was done so that every user is able to add, read, edit wiki pages but let individual identified users handle the approval of the pages in a large wiki library. These details are probably inconsequential.

The real problem is there is a single user who can can read, add, and edit wiki pages. He is also assigned to approve some wiki pages. However, when he attempts to view the history of a wiki page for approval he gets an access denied error. The history page for a wiki page in a wiki library is an application page (in _layouts directory) with the following path: http://<path to sharepoint site>/_layouts/VersionDiff.aspx?ListID=<my wiki library id>&ID=<id for the wiki page>&Source=<return path>

The user also experiences this error when clicking the link to view incoming links. The path for this page is: http://<path to sharepoint site>/_layouts/BackLinks.aspx?ListID=<my wiki library id>&ID=<id for the wiki page>

This user has the following permissions being applied:

• Site Permissions – Limited Access
• List Permissions – Limited Access
• Item Permissions – Design

This user is also part of a domain group which has the following permissions being applied:

• Site Permissions – Limited Access
• List Permissions – Contribute
• Item Permissions – Contribute

Solution

I started a thread in the TechNet SharePoint forum in hopes of finding someone who has run into this problem before. Thanks to the folks in the forums, there were a few suggestions on how to resolve the problem. Unfortunately, I didn’t have the opportunity to try most of these. But here are the suggestions:

• Delete the user from the SharePoint site and re-add the user and re-apply permissions.
• Recreate the AD account
• Assign a higher level privillege to a parent object (This is the band aid that I applied which resolved the problem)

Essentially, the solution is to wrap the SiteActions control with a SPSecurityTrimmedControl in the master page. The only trick to this is identifying the appropriate permission string to use for the control so you do not remove the menu from users who will actually need to use it. The string can easly be composed after reviewing the set of users (or a group of users) who will need access and checking the rights associated permission levels granted those users (or group).

Important details to note are:

• FeatureId (optional): This is the ID of the feature in which the list template is defined
• BaseType (required): Specifies the base type, or default schema, for lists created using this template. See the table below for the 5 possibilities.
• Type: this is the template type on which the new list template is based. Se the table below for all base types of standard SharePoint list templates.
• DisplayName: the display name of the list template.

More details can be found in André Vala’s post.

The following table lists the 5 base types:

Base Type	Description
0	Generic List
1	Document Library
3	Discussion List
4	Survey
5	Issue List

The following table lists all available list templates with their template type id and their corresponding feature id:

Type of list	TemplateId	FeatureId
Generic List	100	00BFEA71-DE22-43B2-A848-C05709900100
Document Library	101	00BFEA71-E717-4E80-AA17-D0C71B360101
Survey	102	00BFEA71-EB8A-40B1-80C7-506BE7590102
Links List	103	00BFEA71-2062-426C-90BF-714C59600103
Announcements List	104	00BFEA71-D1CE-42de-9C63-A44004CE0104
Contacts List	105	00BFEA71-7E6D-4186-9BA8-C047AC750105
Events List	106	00BFEA71-EC85-4903-972D-EBE475780106
Tasks List	107	00BFEA71-A83E-497E-9BA0-7A5C597D0107
Discussion List	108	00BFEA71-6A49-43FA-B535-D15C05500108
Picture Library	109	00BFEA71-52D4-45B3-B544-B1C71B620109
Data Sources	110	00BFEA71-F381-423D-B9D1-DA7A54C50110
Site template gallery	111
User Information List	112
Web Part gallery	113
List Template gallery	114
XML Form Library	115	00BFEA71-1E1D-4562-B56A-F05371BB0115
Master Pages gallery	116
No-Code Workflows	117	00BFEA71-F600-43F6-A895-40C0DE7B0117
Custom Workflow Process	118	00BFEA71-2D77-4A75-9FCA-76516689E21A
Wiki Page Library	119	00BFEA71-C796-4402-9F2F-0EB9A6E71B18
Grid List	120	00BFEA71-3A1D-41D3-A0EE-651D11570120
Data Connection Library	130	00BFEA71-DBD7-4F72-B8CB-DA7AC0440130
Workflow History	140	00BFEA71-4EA5-48D4-A4AD-305CF7030140
Gantt Task List	150	00BFEA71-513D-4CA0-96C2-6A47775C0119
Meeting Series List	200
Meeting Agenda List	201
Meeting Attendees List	202
Meeting Decision List	204
Meeting Objectives List	207
Meeting Things to Bring List	211
Meeting Workspace Pages List	212
Blog Posts List	301
Blog Comments List	302
Blog Categories List	303
Status Indicator (KPI) List	432	7ED6CD55-B479-4EB7-A529-E99A24C10BD3
Report Library	433	6E53DD27-98F2-4AE5-85A0-E9A8EF4AA6DF
Publishing Pages Library	850
Issue Tracking List	1100	00BFEA71-5932-4F9C-AD71-1557E5751100
Administrator Tasks List	1200
Translation Management Library	1300	29D85C25-170C-4df9-A641-12DB0B9D4130
Translation List	1301	29D85C25-170C-4df9-A641-12DB0B9D4130
Slide Library	2100

0BE49FE9-9BC9-409d-ABF9-702753BD878D

• SharePoint jQuery Deployment Feature
• SharePoint + jQuery = Stay Here Feature
• SharePoint Slideshow Web Part

After figuring out how to package jCarousel and jQuery using SharePoint delegate controls, I was ready for business with the implementation of the web part.

The web part itself was nothing fancy. I used a Repeater control to generate the list item (LI) elements with the content I needed in the carousel. I wrapped the Repeater in an unordered list (UL) which was wrapped in a DIV tag that had the runat attribute set to server. So basically, I just followed the mark up instructions provided in the jCarousel documentation.

The wrapping DIV tag was used in my webpart code to initialize jCarousel. The code snippet below shows how I implemented it:

protected override void OnLoad(EventArgs e)
{
  if (!Page.ClientScript.IsStartupScriptRegistered(this.GetType(), this.ClientID))
  {
    Page.ClientScript.RegisterStartupScript(this.GetType(), this.ClientID, @"
      <script type=""text/javascript"">
        jQuery(document).ready(function() {
          jQuery('#" + carouselDiv.ClientID + @"').jcarousel({
            // Configuration goes here
            vertical: true,
            scroll: 2,
            visible: 4
          });
        });
      </script>
    ");
  }
}