Previously, I’ve detailed my attempts to show a query string parameter in a page. This should be a simple enough to do as inline code, but as my previous attempts recorded, when I tried:

<%= Request.QueryString.ToString() %>

I got the error “code blocks are not allowed in this file”. This makes sense, as otherwise anyone with SharePoint Designer could put arbitrary code into a page and get it to run. Clearly, as this would let business users enter code, this would not be very secure.

Now, you can turn off this security restriction using Page Parser Paths, but this reduces the security of the system – again, anyone with SharePoint Designer could put code in without review/authorisation. Again, less than ideal.

Well, one of the things I learnt last week was that uncustomised pages (or ‘ghosted pages‘ for the oldies) will run inline code. Fantastic! After all, we’re going to want to package up our code for deployment from Development to Testing and Production systems, right? (Well, you should be, dammit!)

For those of you who don’t know, uncustomised pages are ones that are stored on the server’s hard drive, rather than in the database. To get onto the hard drive, someone has to install them, which means that someone has to review and approve the code. With SharePoint designer, this isn’t the case, and SharePoint Designer can only create pages that are Customized (or Ghosted), and so exist only in the database.

So overall, the process would probably become:

1. On a development system use PageParserPaths to enable inline code. As this is a dev system, security is less of an issue, and business users won’t be making changes.
2. Develop your pages that use inline code. You can do this in SharePoint Designer.
3. When the pages are complete, copy them out and package into a feature. Make sure that your page that you’ve written in installed Ghosted – still the terminology they use in features.
4. Install and activate the feature. As your page is now uncustomised (or ‘ghosted’), it will now run inline code without PageParserPaths being configured.

That’s a pretty tidy developer story!