First things first, thanks to Jomit for his Dialog Platform post, which served as the basis for my work herein.

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.