InfoPath FormViewer Webpart

It's been a while since I last posted and there is a very good reason for it! I will save the reason for another post in the very near future but right now I wanted to share this webpart I've been working on. As the title suggests it's a webpart that views the content of an InfoPath form. Now it's not a webpart that just renders the xsn file (like the FormViewer webpart). No, what it does is displaying all the promoted columns of a particular submitted form.

The big question is ofcourse.. "Robin.. why on earth did you build this" Well it has something to do with posts I made in the past ((Approval) Workflow thingies continued & (Approval) workflow thingies) where I copied information from the promoted columns of the form into a tasklistitem. By doing this, an user can easily see what he/she needs to approve in just one or two click(s). Now I was getting tired to copy every promoted column by hand in SPD for each Action I created per step. So I decided to build a webpart which did the following :

• Show the promoted columns without specifying them per form
• Show headers to group columns
• Have the ability to Approve or Reject the form
• (optionally) show the approver which phase of the workflow status he/she is approving

Now within defining the workflow in SPD, the only thing I need to copy each time into a new taskitem is the ID of the form and the person who must approve that step. The webpart takes care of the rest by using that information. How? Well you drag the webpart onto the 'editform.aspx' page of the task list. Using this page, it will give me the ID of the task (querystring in the URL) and by having both ID's (task and form) I can display and update the information.

Now a screenshot tells you more than a lot of words so here's what it looks like:

Pretty impresive eh? (I know I need to fix the layout;) .. Now the only input this webpart needs is the following :

• FormLibraryName, the name of the library where the information should be fetched from
• Name of a view, this view is being used to show the columns that you want to have in the webpart.
• TaskName, the name of the tasklist where the tasks are created for the workflow
• Headers, a comma separated string where you can specify where headers should be placed and what the title should be.

So how does the code look like? Well.. it's quite big so I will only post the relevant stuff.

• Hiding the default EditForm formfield

writer.Write("");

• Getting the reference of the taskitem and the formitem

SPWeb web = SPControl.GetContextWeb(Context); SPList tasklist = web.Lists[_tasklist]; SPListItem taskitem = tasklist.GetItemById(Convert.ToInt32(Page.Request.QueryString["ID"]));  SPList formlist = web.Lists[_formlibrary]; SPListItem formitem = formlist.GetItemById(Convert.ToInt32(taskitem["ListItemID"].ToString()));

• Displaying the status of the workflow by using a column named "Status" in the formlibrary

SPFieldChoice status = (SPFieldChoice)formlist.Fields["Status"]; writer.Write(""); foreach (string _status in status.Choices) {     if (_status == formitem["Status"].ToString())     {         writer.Write("");     }     else     {         writer.Write("");     } } writer.Write("
");          writer.Write(_status.ToString());         writer.Write("
");         writer.Write("You are here");          writer.Write("
");         writer.Write(_status.ToString());         writer.Write("
");         writer.Write(" ");         writer.Write("
");

• Displaying all the columns based on a view. And when given, display a header

//Render the columns with their values based on the view that is selected writer.Write(""); SPView view = formlist.Views[_view]; System.Collections.Specialized.StringCollection strCollection = view.ViewFields.ToStringCollection();  for (int i = 0; i < splitter =" {" seperator =" _separators.Split(splitter);" x =" 0;" _splitter =" {" colom =" seperator[x].Split(_splitter);" y =" 0;" i ="=">");                     }                     break;                 }              }         }         finally         {              //Write all the columns that are in the view with their values             writer.Write("");             writer.Write("");         }     }     catch (Exception error)     {         writer.Write(error.Message.ToString());     } } writer.Write("
 
" + colom[1] + "
");             if (formitem.Fields.GetFieldByInternalName(strCollection[i]).Title != null)             {                 //ColumnName                 writer.Write(formitem.Fields.GetFieldByInternalName(strCollection[i]).Title);             }             writer.Write("
");             if (formitem[(strCollection[i])] != null)             {                 //ColumnValue                 writer.Write(formitem[(strCollection[i])].ToString());              }             writer.Write("
");

InfoPath Forms in Office SharePoint Server 2007

I’m sure it comes as no surprise that Office InfoPath 2007 is the forms designer of choice for Office SharePoint Server 2007. But the average SharePoint developer, used to reaching for ASP.NET when he needs to create a form for SharePoint, might be surprised at all the places you can employ InfoPath to quickly create forms for enterprise management functions.
The main reason for this is the fact that in InfoPath 2007 you can create what the InfoPath guys are calling symmetrical forms. Symmetrical forms are InfoPath forms that can be hosted either in the Office client applications like Word, PowerPoint, and Excel, as well as in the SharePoint Server browser interface. So you can create a single form, and know it’ll look and work the same whether the user sees it in an Office application or in the browser interface.
(How is this possible? Short version: SharePoint Server 2007 uses Office Forms Services, a server-based run-time environment for InfoPath 2007 forms, to host the forms in the browser. Office Forms Services consumes the forms you create in the InfoPath client and renders them in an ASP.NET framework, which acts as a run-time environment for the form. This environment presents a form editing experience that matches the InfoPath 2007 client application. The Office client applications, on the other hand, include the ability to host the native InfoPath forms. )
So naturally, symmetrical forms are very handy for enterprise content management areas, where the user might be working with documents in their native client application, or online through the SharePoint Server browser interface.
Here’re a couple of the places where you can employ InfoPath forms for enterprise content management in SharePoint Server 2007:
· Document Information Panels
A document information panel is a form that is displayed within the client application, and which contains fields for the document metadata. Document information panels enable users to enter important metadata about a file anytime they want, without having to leave the Microsoft Office system client application. For files stored in document libraries, the document information is actually the columns of the content type assigned to that file. The document information panel displays a field for each content type property, or column, the user can edit.
You can create document information panels either from within SharePoint Server, or directly from InfoPath 2007.
How to: Create or Edit a Custom Document Information Panel from within Office SharePoint Server 2007
How to: Create a Custom Document Information Panel from InfoPath
· Workflow Forms
You can create InfoPath forms for use with workflows in SharePoint Server 2007. That way, the user can interact with the workflow form from within the Office client application, and not just through the browser.
SharePoint Server 2007 uses Office Forms Services to display workflow forms, be they association, initiation, modification, or edit task forms. The only difference is that there’s a different .aspx page hosting the Office Forms Services control for each type of workflow form. Initiation forms are hosted by a different .aspx page than modification forms, for example. Each different hosting page knows how to submit the information from its type of form to SharePoint Server (and hence, to the workflow engine).
The .aspx pages that contain the Office Forms Services web part are included as part of SharePoint Server, of course.
How to: Design an InfoPath Form for a Workflow in Office SharePoint Server 2007
So if your putting together an enterprise content management solution in Office SharePoint Server, and you’d like your user to be able to interact with your custom forms in the client application and the browser, it might be worth your while to take a look at InfoPath 2007 and Office Forms Services.