So, I recently had occasion to open up a browser-based Forms Services form from outside of the site collection where the template and the "Save Location" both reside…you know, kind of like one of those completely unplanned "Real World Scenarios" that we are always hearing about.

Anyway, anyone that has opened up a Forms Services form in the browser has noticed the extremely long URL that is necessary. For the uninitiated, here is a very quick synopsis of the various portions of the URL.

• Base URL. Forms Services forms are processed by an ASP.NET page located in the layouts folder. This is the base URL and it looks like this:
  • http://<<URL to your site>>/_layouts/FormServer.aspx
• Query String. There are various query string parameters that you may or may not have, depending on your situation.
  • XsnLocation. This is the location of your Form Template, and it looks something like what appears below. If you click on the "New" button in a document library configured to use the form, this parameter is NOT encoded, although the others are…it's probably a good idea for you to encode all of them if you are building your own long-ass URL from scratch. For the sanity of anyone reading, I am not going to show encoded stuff here. If you would like a quick and easy way to encode/decode stuff, here is a good one.
    • XsnLocation=http://<<site>>/Form Templates/Template Name.xsn
  • Save Location. This is usually optional, as the form will just submit to the Document Library specified in the form template if this parameter is not there. Here is what it normally looks like:
    • SaveLocation=http://<<site>>/Documents
  • Source. This is the page you want to bring up after the user is done with the form…and is the source of the challenge I had that started this whole darn thing. Basically, if you try to pass a Source parameter that is from a different site collection, Forms Services will treat you like a pigeon treats a statue. Here is what this parameter looks like:
    • Source=http://<<site>>/Pages/Success.aspx
  • DefaultItemOpen. This parameter is used to force the form to open in a browser. If it is set to something other than '1' or not present, the form will try to open in InfoPath. Here is what the "open in browser" option looks like:
    • DefaultItemOpen=1
• The Whole Damn Thing. So, if you put all that stuff together, it looks something like this:
  • http://docs.company.com/sites/active/_layouts/FormServer.aspx?XsnLocation=http://docs.company.com/sites/active/Form Templates/Template Name.xsn&SaveLocation=http://docs.company.com/sites/active/Documents&Source=http://docs.company.com/sites/active/Documents/Forms/AllItems.aspx&DefaultItemOpen=1

So, I am not sure if you caught on to the main issue reading through all that junk, but here it is in a nutshell. If you try to pass in a "Source" parameter that is from a different site collection than the one where the template is located, Forms Services will barf. That kind of puts on damper on my "Real World" scenario of having the users access a centralized landing page / application, while exhibiting a higher level of control over the document processing center where the forms are going to be filled out.

I know what some of you might be thinking – just use a new window/tab. The problem with that is that not everyone likes popups, plus, sometimes you end up with a useless popup sitting there just displaying "The form has been closed" in the middle of the screen. Besides, popups are just so Web 1.0. Modal windows, that's wave of the future, man!

For those of you that have seen SharePoint 2010 in action, you know Microsoft has gotten behind the whole modal window thing as well. In fact, if you have access to a SharePoint 2010 box, go ahead and type in the URL to the Upload form of one of your document libraries (http://<<site>>/Documents/Forms/Upload.aspx). SharePoint will get the standard Upload page from the _layouts folder, and it pretty much looks like a normal SharePoint page, right? Now, add in a query string parameter so it looks like this (http://<<site>>/Documents/Forms/Upload.aspx?IsDlg=1). See that? That form is damn sure ready for a modal dialog, huh? In fact, it is the standard way that Microsoft allows users to upload documents to a library, by putting the Upload form in a modal window and using the IsDlg parameter to keep all the extraneous stuff from showing up.

Well, that's not the only place where Microsoft has bought into this whole modal window thing. As it turns out, there is a JavaScript method set up for this that comes along with the ECMAScript Class Library that you can use from just about any SharePoint page. Check out Jomit's post that I referenced above for a little more detail and the links to learn more about the method and the ECMA library.

Since the FormsServer.aspx page doesn't even recognize the IsDlg parameter, I didn't even need it. So, armed with everyone's favorite way to hack a SharePoint page (the Content Editor Web Part), I set out to get my InfoPath form to open up in a modal window. Here is the code that got it to work:

<script type="text/javascript">

//Handle the DialogCallback callback

function DialogCallback(dialogResult, returnValue)

{

}

//Open the Dialog

function OpenModalDialog(dlgURL)

{

var options = {

url: dlgURL,

width: 700,

height: 700,

dialogReturnValueCallback: DialogCallback

};

SP.UI.ModalDialog.showModalDialog(options);

}

</script>

//Link to InfoPath Form

<a href="javascript:OpenModalDialog('http://docs.company.com/sites/active/_layouts/FormServer.aspx?XsnLocation=http://docs.company.com/sites/active/Form%20Templates/Form%20Template.xsn&amp;SaveLocation=http%3A%2F%2Fdocs%2Ecompany%2Ecom%2Fsites%2Factive%2FDocuments&amp;DefaultItemOpen=1');" onmouseover="javascript:window.status='';return true;" onmousedown="javascript:window.status='';return true;">Coolest Form Ever</a>

So, you see that I have gotten rid of the "Source" parameter in the Query String, as that still breaks the form if you send it something that is in a different site collection than the template, but the UX is about 100 times better than having a popup or (even worse) sending them to a page that is on a different site collection than where they started.

I still need to move this out of the CEWP before it is ready for prime time, but just think about the implications here. This is a bona fide slam dunk and a huge win for Microsoft by allowing us to quickly deliver solutions that are in line with what others are doing in the industry.

You can download the web parts at my company web site:  www.theportalgroup.biz

Just click on “Downloads”, register for free, and they are all yours.

UPDATE:  Registration is no longer required…and in an unrelated note, special thanks to the over 200 new registered users with a username of “asdf”…I really appreciate it. <grin />

In case you have not read the blog posts yet (and don’t want to), here is the basic overview:

• QueryString Pass-Thru Web Part.  The first web part will pass through the entire QueryString from the parent Web Part Page, append it to a Base URL, which the user can configure in the tool pane, and display the contents at the concatenated URL in the PageViewer web part.  This is especially useful when you want to link to display content from several external pages that are all part of the same site, with a URL format that looks something like this:  http://intranet.company.net/Default.aspx?pageid=420.  If you wanted to display the contents of 40 different pages in SharePoint using the standard PageViewer web part, you would need 40 separate web part pages, each hard-wired to the target URL.  Using the QueryString Pass-Thru Web Part, you can just set up one Web Part Page, and pass it a QueryString parameter with the pageid every time you want to use that page.
• QueryString Parameter Pass-Thru Web Part.  This web part will pass through a QueryString parameter called ‘Url’ (‘url’ and ‘URL’ will work as well), which contains a properly formatted URL, to a PageViewer web part that will display the contents at that URL.  This is useful for a situation where you want to display content from several different external pages that are specific and separate pages, not just differentiated by the QueryString (e.g. http://intranet.company.net/hr/Deafult.aspx, http://intranet.company.net/finance/Default.aspx, etc.)  The benefits are the same as the QueryString Pass-Thru Web Part…you only need one web part page that you can use to connect out to any page, vice needing a separate web part page for every connection, if you were using the standard PageViewer web part.

There are a few caveats to keep in mind as well.

• QueryString Pass-Thru Web Part.  You cannot use a QueryString parameter named ‘id’.  SharePoint will think it needs to look for an ID of its own with that value, and you will get an error on the page.
• QueryString Paramter Pass-Thru Web Part.  Be careful of the characters you are using in your ‘Url’ parameter.  It is a good idea to use the HTML character escape sequences.  For instance, if you want to pass a URL that has a query string, you will need to use the escape sequence for the question mark and ampersand(s) or else the code with think the ‘Url’ parameter has ended before you wanted it to end.

Hope you enjoy the web parts, and please feel free to let us know what you think.

Oh – one more thing.  If you are interested in expanding on these or otherwise developing them yourself, you can get to the blog posts at the links below.  The first one even has a Screencast that might help those without a lot of SharePoint development experience.

Passing Through the Entire Query String

Passing Through a Single Parameter in the Query String

If you are like me and do a lot of demos, especially ones that are running within a virtual environment (Virtual PC, VMWare Server, etc.) you have probably struggled with the best way to demonstrate the e-mail capabilities of whatever you are going to demo.  In my case, Microsoft SharePoint is what I am trying to show, and although there are a few integration touch points only present in Microsoft Exchange, it is a resource hog and kind of a pain to install and maintain, especially if you are not an Exchange administrator.

Enter AXIGEN mail server.  First things first, I have never played around with the “pay” versions of AXIGEN, but according to their web site, the free “Office Edition” is essentially their full-featured product, with a restriction of 5 users and 1 domain…more than enough for a small office, or a demo VPC or VM.

On their web site, they claim that you will have a 10-minute install, which is true…although if you are going to install and use their Active Directory extension, you can probably add another 5 minutes or so.  All told, the very first time I used it, it took around 20 minutes from the time I started the download until I was up and running, with integration to my Windows Server 2003 Domain (Active Directory) and robust full-featured web mail running on a custom port of my choosing.  The second time I set it up, it took me all of 6 or 7 minutes, start to finish.

I have not played around with AXIGEN versions for any other operating system than Windows, but if my experience on Windows is typical of how it works on other operating systems, then you should have nothing to worry about.

I cannot say enough positive things about this little product.  In fact, some time in the next few months, Mack is going to start bringing a lot of his stuff “in house”, as in having a home office with one or 2 “server class” machines, getting a block of static IP addresses, and starting to do a lot of my own hosting for certain domains that I manage, including e-mail.  After my first exposure to AXIGEN, Microsoft would probably have to pay me to install and use Exchange.

Feel free to download the product and try it out yourself.  You will NOT be disappointed.

http://www.axigen.com

One more thing I would be remiss if I did not mention – it installs and runs on non-server Windows operating systems as well.  Couple AXIGEN with Bamboo Solutions’ WssOnVista, and I can do a full-featured demo within my host operating system, instead of even worrying about Virtual PC or VM Ware.  Now THAT’S something worth telling people about!

The QueryStringPageViewer Web Part allows a user to configure the Web Part with a Base URL attribute, then fills up the web part’s IFRAME by concatenating the Base URL with the query string of the web part page, using Page.Request.QueryString.  The best use for this web part is when you have a bunch of pages you want to link to on a different server, where the URL format of those pages looks something like this:  http://intranet.company.com/Default.aspx?pageid=4563

But what about a situation where the existing pages are all distinct, such as:  http://intranet.company.com/Finance.aspx, http://intranet.company.com/HR.aspx, http://intranet.company.com/Manufacturing.aspx, etc.?  Let’s say you had 40 of those pages that you wanted to expose within SharePoint in an effort to incorporate existing content sources.  If you were going to use the standard PageViewer Web Part, you will need to create 40 separate Web Part Pages, each with a PageViewer Web Part wired up to the URL of one of the 40 pages.

So, what about making a generic web part that uses a query string parameter from the web part page, a la my previous blog post referenced above, to dynamically set the source of a PageViewer web part?  What if you could deploy that simple web part on a “generic” web part page and reference it anywhere in your SharePoint implementation that you need to use a PageViewer web part?  Would you rather have 40 instances of the PageViewer web part in your environment or one instance of this new web part, called the DynamicPageViewer web part?

As you would expect, the code is very similar to the code from my last blog post, as we will be using the Page.Request.QueryString object once again.  Here are the steps you need to take to change that code to perform this new function.  More detailed instructions on creating the project, deploying the web part, etc., can be found in the last blog post.

Here are the steps required:

• Get the code from the previous version, where we use the entire query string.  It is located here:  http://www.themackpage.com/files/Dynamic-PageViewer-Web-Part.txt
• Find and remove this code: 

  //Set custom attribute to allow user to specify Base URL in Tool Pane
  private string _baseURL = "";
  [WebBrowsable(true),
  Personalizable(PersonalizationScope.Shared),
  Category("Base URL Settings"),
  WebDisplayName("Base URL"),
  WebDescription("Supply the Base URL for the page viewer query string web part.")]
   
  public string baseURL
  {
      get
      {
          return this._baseURL;
      }
      set
      {
          this._baseURL = value;
      }
  }

• In the RenderWebPart method, replace this code: 

  NameValueCollection queryString = Page.Request.QueryString;
  string URL = this.baseURL;
  int paramCount = 0;
   
  if (queryString.Count > 0)
  {
      // Set up URL as having a Query String
      URL += "?";
   
      // Loop through QueryString collection and add all name/value pairs to 'URL'
      foreach (string qsName in queryString)
      {
          // Add name/value pair for current key to the URL
          URL += qsName + "=" + queryString[qsName];
   
          // Add ampersand for all but the last query string parameter
          paramCount++;
          if (paramCount < queryString.Count)
              URL += "&";
      }
  }

with this:

NameValueCollection queryString = Page.Request.QueryString;
string URL = "";
if (queryString.Count > 0)
{
    // Loop through QueryString collection
    foreach (string qsName in queryString)
    {
        if (qsName.ToLower() == "url")
            URL = queryString[qsName];
    }
}

See?  I told you it was super simple!

Once you get the web part deployed and on a web part page, type in any random query string at the end of the URL for the web part page, making sure to include a parameter called url that actually contains a valid URL (note the use of "ToLower()" in the code, so url, URL and Url are all supported). For example, replace http://intranet.company.com/TestSite/Pages/WebPartTest.aspx with http://intranet.company.com/TestSite/Pages/WebPartTest.aspx?pageid=1999&red=green&url=http://autos.msn.com&napster=bad

The custom web part should be blank, and then when you add the query string with the url parameter, it will fill up with the MSN Autos page.

ADDENDUM:

In certain situations, you will need to use url escape codes in the ‘url’ parameter.  For instance, if the URL you are targeting has a query string, you need to use the escape code for the “question mark” (%3F) to start the query string and use the escape code for the “ampersand” (%26)to delimit the parameters.  If you fail to use the escape codes, you will not achieve the desired results.  Using the escape code for “equals” (%3D)is not required, although it might make sense to adopt a standard convention where you use the escape code for all eligible characters within the ‘url’ parameter.

If you are lucky enough to have a development environment with even better tools, as I am sure most of you do, then please feel free to use whatever best tools you have as you make your way through this. 

Also, there is a supporting screencast for this blog post that contains much more detailed information.  You can find it here:  http://www.themackpage.com/screencasts/dynamic-pageviewer-web-part

Without further ado, let’s get down to it.  Here are the steps to create your very own dynamic PaveViewer web part.

• Make a SharePoint Web Part project in your development environment of choice.  For the purposes of this exercise, I will be using the generic Class Library project in Visual C# 2008 Express.  If you are using the Visual Studio Extensions for WSS, then you will be able to skip the next few steps.
• Rename the Class1.cs file in the Solution Explorer.  
• Right-click the class name and select Rename
• Change the name and hit Enter
• Something cool in the 2008 dev tools (even the free one) is about to happen – you will be asked if you want the IDE to search and fix other instances of the reference to Class1.  Click Yes and watch the class name in the editor change before your very eyes!

 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.WebPartPages;
using System.ComponentModel;
using System.Collections.Specialized;
 

 
public class QSPVWP : Microsoft.SharePoint.WebPartPages.WebPart

 
//Set custom attribute to allow user to specify Base URL in Tool Pane
private string _baseURL = "";
[WebBrowsable(true),
Personalizable(PersonalizationScope.Shared),
Category("Base URL Settings"),
WebDisplayName("Base URL"),
WebDescription("Supply the Base URL for the page viewer query string web part.")]
 
public string baseURL
{
    get
    {
        return this._baseURL;
    }
    set
    {
        this._baseURL = value;
    }
}
 

 
NameValueCollection queryString = Page.Request.QueryString;
string URL = this.baseURL;
int paramCount = 0;
 

 
if (queryString.Count > 0)
{
    // Set up URL as having a Query String
    URL += "?";
 
    // Loop through QueryString collection and add all name/value pairs to 'URL'
    foreach (string qsName in queryString)
    {
        // Add name/value pair for current key to the URL
        URL += qsName + "=" + queryString[qsName];
 
        // Add ampersand for all but the last query string parameter
        paramCount++;
        if (paramCount < queryString.Count)
            URL += "&";
    }
}
 

 
string name = "QueryStringPageViewer_" + this.UniqueID;
output.AddAttribute(HtmlTextWriterAttribute.Id, name, false);
output.AddAttribute(HtmlTextWriterAttribute.Name, name, false);
output.AddAttribute(HtmlTextWriterAttribute.Width, "100%", false);
output.AddAttribute(HtmlTextWriterAttribute.Height, "100%", false);
output.AddAttribute(HtmlTextWriterAttribute.Src, URL, false);
output.AddAttribute("ddf_src", URL, false);
output.AddAttribute("frameBorder", "0", false);
output.RenderBeginTag(HtmlTextWriterTag.Iframe);
output.RenderBeginTag(HtmlTextWriterTag.Div);
output.Write("IFrames not supported by this browser");
output.RenderEndTag(); //Div
output.RenderEndTag(); //Iframe