Dan Holme
Office & SharePoint Pro
Community Manager
Hi from Beijing, where I'm serving as the Microsoft Technologies Consultant for NBC television to help bring the 2008 Beijing Olympic Games to television and the Internet. I've arranged for several guest columnists to fill in for me when I'm not able to write a commentary. This week, SharePoint MVP Jeremy Sublett finishes his two-part article comparing two forms-based technologies for SharePoint: Microsoft Office InfoPath and SharePoint Designer Forms Enjoy! Comparing InfoPath and SharePoint Designer Forms, Part 2
In Part 1 of this series about forms-based based technologies for SharePoint, I discussed Microsoft Office InfoPath forms (using Forms Services). In this article, I discuss forms created with SharePoint Designer and offer a point-by-point comparison of the features of both technologies.
SharePoint Designer
SharePoint Designer, also part of the Microsoft Office suite, is the replacement for FrontPage and has all the capabilities of that tool, plus much more. It also contains all the functionality contained in the Expression Web tool, a popular web-editing tool. SharePoint Designer is useful for editing files of websites that support FrontPage extensions as well as those websites that are simply file-based. Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) 3.0 are included in this mix, of course. And since SharePoint is an ASP.NET 2.0 application, we’re often editing things such as CSS style sheets, ASP.NET pages, and ASP.NET master pages. Here are some of the many features of SharePoint Designer: - It can work with SharePoint’s virtual file system, allowing you to name/move files and folders of any type.
- Workflow creation capabilities are allowed via a simple wizard.
- It works with standard and custom ASP.NET User Controls.
- It offers Visual support for Master pages (including multi-level master pages).
- It has a visual designer and code editor with split view.
- It has file-editing capabilities (.aspx, .master, .css).
- It offers strong IntelliSense support (e.g., in XSLT transformations and cascading style sheets).
- It can work with MOSS 2007 as well as WSS 3.0.
The process of creating a form in SharePoint Designer is relatively easy. You start by creating a SharePoint list to contain your information, with the columns of data you desire. Then you use SharePoint Designer to create a new .aspx page in your site. This page is used to render the form. The following set of steps walk you through the process of creating two .aspx pages that replace the standard new and edit forms for a list. These will appear just like the InfoPath form created in Part 1 for the absence request business process, minus some formatting. 1. First you need to create a list to store your form results. Just create a list called Absence Request and add the following columns: 
2. Next, in SharePoint Designer, open your SharePoint site. Create a blank .aspx page called NewForm2.aspx in the folder for the list you just created. Note that you could create this .aspx page anywhere, but we’ll keep it here for consistency. 
3. Next, enable the Data Source Library task pane from the Task Panes menu. This shows all your data sources, which includes lists, document libraries, XML files, databases, and more. Choose the menu next to the Absence Request list and choose the Show Data command. 
4. Choosing the Show Data command will then show you all the columns of the list. Now you’ll select multiple columns and open the drop-down menu above the columns. Choose the New Item Form option to create a form for creating new items in your list. 
5. Now you've added a new form to your .aspx page. At this point you have a fully functional form that will save data to the list. You can also format the form, re-order fields, or even attach a master page to it. 
6. To make this form show up when you click the New button on your list, you need to right-click the list in the folder listing and choose Properties. Navigate to the Supporting Files tab to choose the new form you created as the new item form. 
7. Finally, you might want to control where users are sent after they complete a form. To do this, right-click the Save button of the form. Then choose Form Actions. A dialog box will appear that gives you the ability to direct where users go. Choose Redirect to Source to send the user back from where they came. After this, you can use your form by clicking on the new menu of your list in SharePoint. 
8. The steps so far only create a form for adding new items. If you want a custom editing form, you can walk through the same steps above to create EditForm2.aspx in the same place. When creating your form, you would choose the Single Item Form. 
9. This is used for rendering a single item in a form view. The single item needs to be selected, however. To do this, you need to pull the ID parameter off the query string. You do this by creating a new parameter and filtering on your list. 
And then the filter... 
10. Finally, you must choose this form as the default edit form for the list and change the form action so that it sends users back to where they came from. Once this is done, you have control over the user’s editing experience. Comparison
Although these two tools can be used in a lot of different ways, I’m only comparing them from the perspective of the absence request scenario used in both of the earlier examples. Here’s the scenario for each tool: - InfoPath forms are being submitted to a SharePoint document library and the form is rendered in a browser.
- SharePoint Designer forms are submitting items to items in a list. Although a SharePoint list already comes with forms for creating new entries and editing existing entries, these forms are replaced here with custom .aspx pages, described in the steps above.
Here's a table showing the differences in functionality between InfoPath and SharePoint Designer. Functionality | InfoPath | SharePoint Designer | | Design experience | A very easy design experience with powerful wizards and many formatting options. | A design experience much like that of the declarative Visual Studio environment. Not too bad, but some things require confusing steps. | | UI integration | By default InfoPath has a separate page for rendering the form. Co-mingling an InfoPath form with a MasterPage can be done with more steps than the SPD process. | Since you have full control of the ASPX page that hosts the form and the entire HTML around it, the UI experience is much better. | | Variable passing | It is difficult to consume query string variables. | Easy to do with input parameters, filters and their corresponding wizards. | | Anonymous support | Document libraries require that users be authenticated. Since the results of the form are stored in a document library, this can pose a problem. This can be achieved using a custom guest membership provider. | Works fine as long as the underlying list has anonymous access enabled. | | Form validation | Extensive support of field validation with an easy wizard-based approach. | Can be done by using ASP.NET validation controls. | | Dynamic items | Can easily support dynamically growing items. | Difficult to achieve and would typically require a secondary list to contain multiple values. | | List column support | Most fields from a form submission can be promoted to columns in the document library. | These forms are entirely based on list columns. | | Speed | These forms can render slower than SPD, depending on the complexity of the form. | These forms are quite fast and load with the rest of the page. | | Portability | The InfoPath form is very portable, its views and formatting elements are self-contained in the XSN file. | The forms used here are very much tied to the lists they depend on and, thus, are not very portable. Where not tied to lists, the form can be moved by moving the .aspx file(s). | | Field lookup support | InfoPath has a rich set of wizards that allow form data to be populated from numerous sources, thus populating controls such as drop-down lists. | Since ASP.NET is behind the scenes here, users can use data source controls to pull in data from other sources. These sources can populate ASP.NET form controls. |
Clearly these tools have many more advanced capabilities than I was able to touch on here, but where they overlap, users may be left confused about their options. I hope this article can serve as a guide for you in those situations. Jeremy Sublett is a software architect and senior partner with Composable Systems, LLC, specializing in SharePoint-based business solutions and is a Microsoft SharePoint MVP. Website
|