Toth’s Tales from the Trenches

Overview

The current migration project I am working on is migrating a very large, 8 year-old portal and all its contents from an archaic BroadVision platform to MOSS 2007. BroadVision is absolutely one of the worst portal software packages I have ever seen, and is proving to be quite difficult to migrate into MOSS 2007. This is part 1 of an ongoing series of stories about this project and its challenges.

Migrating Forms

BroadVision has support for a crude version of custom web forms, that can be used to collect data and either email the data or save it in a database. These forms are standard html forms with html form tags, and almost all of them have a spot at the top of the form where some introductory html is placed to instruct the user on how to use the form, the form's purpose, etc. This project has about 200 of these forms, for almost every department in the organization.  These forms have very little workflow, with just some primitive options to email or CC people when new forms are submitted. There is no easy way to automate this migration.

Below is an example of one of these forms, which is a form to update an employee's address:

InfoPath vs Custom Lists vs ASP.NET Web Applications

The first decision to be made in migrating these forms is choosing the right technology. I presented 3 options to the customer:

• InfoPath – Pros: Flexible, supports validation, custom actions and workflows, can save data to sharepoint lists, libraries, and external databases. Cons: Requires training and design skills, and sometimes coding and development efforts
• Custom SharePoint Lists – Pros: Anyone can do it, easy repository for data, built-in export to Excel, Datasheet view, MOSS 2007 workflows. Cons: Limited validation support, little or no design control, data can only be placed in SharePoint
• Custom asp.net web application – Pros: Complete control over design and storage. Cons: Requires development effort

With over 200 forms to migrate, very little resources, plenty of new forms yet to be created, and lots of forms that need updating or reviews, the customer wanted every department to own, migrate, and create their own forms. The best solution in this case was the one that empowered the end users to create and manage their own forms as easily as possible.

For 90% of the forms, the custom list was the right approach, unless a form needed advanced features like validation, pre-population, etc. The only stumbling block then was having the ability to edit the form that is displayed when you create a new item (NewForm.aspx).

Introductory Text and HTML

Every form in the old portal had a space at the top where introductory HTML could be placed to provide instructions. Since a custom SharePoint list uses the default NewForm.aspx page when adding a new item, there is really no place where this intro HTML could be placed. To solve this, we used a special querystring to put the NewForm.aspx page into edit mode, where we could add a Content Editor Web Part above the form's contents.

Following is the method for getting this to work:

1. Go to the custom list and click the menus to add a new item.
2. On the New Item form, add a querystring parameter to the end of the url, and hit enter. For example, a typical New Item form's url might be:

   http://intranet/Docs/Lists/Tasks/NewForm.aspx?RootFolder=%2fDocs%2fLists%2fTasks&Source=http%3a%2f%%2fintranet%2fDocs%2fLists%2fTasks%2fAllItems.aspx

   Add the following text to the very end of the url: &ToolPaneView=2

   The new URL becomes:

   http://intranet/Docs/Lists/Tasks/NewForm.aspx?RootFolder=%2fDocs%2fLists%2fTasks&Source=http%3a%2f%2fintranet%2fDocs%2fLists%2fTasks%2fAllItems.aspx&ToolPaneView=2

3. This puts the page into Edit mode, and displays the Add Web Parts toolpane. Click Next until you see the Content Editor Web Part. Drag it into the Web Part Zone at the top of the page.

   

4. In the newly added part, click the link to open the Tool Pane ("To add content, open the tool pane and then click Rich Text Editor.") , and paste your introductory text into the Rich Text Editor. When done, click OK, your instructions are now live on the Form.

Granted, telling an end user to hack a querystring to add a web part is not the most user friendly approach, but it is certainly something that can be documented well, and is certainly easier than InfoPath training. Of course this step could also be done easily with SharePoint Designer, but that is another layer of complexity that the users don't need.

This entry was posted on Monday, October 15th, 2007 at 1:22 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.