Clean URLs for Your ASPX Pages with a Document Library and Module

Intro

Which URL is nicer? This one:

/_layouts/northwind/hr/Default.aspx

Or this one:

/hr/Default.aspx

If you're like me, you notice the friendliness of URLs in web applications. I picked up a sense of URL friendliness during my time in the Ruby on Rails community, where they have a predilection for short, semantic URLs.

I'm going to discuss a technique for organizing and deploying custom ASPX pages to your SharePoint environment that will leave you with nicer URLs.

Deploying Pages to /_layouts/

The first URL listed above indicates a page that was deployed to the "layouts" folder in the SharePoint "hive". I'm going to assume that all SharePoint developers are familiar with this process. If you put a page in the "layouts" folder, it's going to be addressed with a URL starting with /_layouts/.

If you want to be a good citizen of your SharePoint farm, you're going to make a subdirectory for the files related to your application to live to keep things tidy. Using my SPMeta-Northwind project as a reference, it would probably make sense to call this subdirectory something like "northwind".

Let's say that Northwind has some custom pages that are related to the Human Resources (HR) department of the company. Again, for purposes of tidiness, we'll group these pages together in a subdirectory called "hr".

So all of our HR-related pages will get a URL that starts with /_layouts/northwind/hr/.

We can do better!

Deploying Pages to a Document Library

Here's another way to deploy our HR-related pages that will result in nicer URLs. It involves a document library and a module.

The SPMeta-Northwind project has a "Lists" folder. Let's add a document library list instance to it called "HR Pages".

Under the Northwind.Common project, we'll add a module called "HRPages". Now let's add a few pages to the module. Note: If you try to add a page to the module by choosing the "Application Page" item, Visual Studio freaks out and adds files completely outside of the module. I always add a "Text file" and manually change the extension to ASPX. After adding our pages, there are some tweaks to make to the module's Elements.xml.

Let's also go ahead and take a preemptive measure to ensure that if we add new pages to the module in the future, they'll be pushed out during feature upgrading. Specifically, we need to reference our module inside an ApplyElementManifests tag.

After activating/upgrading our feature, I'll navigate to /hr in a browser. ASP.NET will look for a Default.aspx file, and since we deployed one, that's where we'll end up.

If you go with the document library + module approach for your custom pages, a nice bonus you get is that you can easily hook into SharePoint's item-level security to secure your pages. Since each page is now an item in a list, you can apply permissions to them just like any other list item in SharePoint. Specify which groups/users have read permissions on the list item, and SharePoint will give its standard "access denied" message to unauthorized users that try to navigate to the corresponding page.

Closing

I prefer the document library + module approach for deploying custom ASPX pages. It's a great way to get clean, short URLs. And you get SharePoint's built-in security enforcement for free!

Categories: