Infopath 2010

10 InfoPath tips for SharePoint developers

Here are 10 nice tips designed for someone that's familiar with SharePoint, but may be new to InfoPath.

Having brooded over the idea for a while, I decided to quickly write this down, and if there are any questions I can expand some of these key points.

1. Use InfoPath Designer 2010 to author your forms, even for 2007 forms. The UI is better, design checker gives you more information, and the rules editor supports copy/copy all and paste. 
   Note: design checker gives you a lot of warnings and sometimes... they can be ignored. Which ones are safe and which aren't... is as far as I know, a personal experience thing, think of it as VS.NET warnings.
2. Design your main context fields first, and then try your best not to change existing fields (add new fields are OK). Removing or renaming fields often break existing forms that had already been filled out.
3. Decide upfront whether this is a rich form or a browser form, and set the compatibility level appropriately. Use the design checker. 
   If you are planning to create hybrid forms that works on both - there's a form option that will allow your code behind to use the Rich Form API but still check the form for Browser Form compatibility. In this case, always check in your code whether the form is running in the browser before you call those APIs, otherwise you will get UnsupportedExceptions.
4. If you need to promote InfoPath fields to SharePoint so they appear as columns (and can be used in workflows), you should always use site columns. You might want to consider always using Content Type as well. 
   It may be tempting to use publish to list - but this creates list fields that are now very hard to manage, and when you realize down the road that you should have used content types, you now have to fix existing list columns and move their data to the site columns. This always happens.
5. Brush up on your XPath skills well. InfoPath renders every view via a XSLT transform and the output is actually a HTML page (either for rich form or web forms). You need to use XPath when you want to start defining rules that are relative to the current field. Why use rules when you can use code behind? See next point.
6. Code behind are powerful, and may look much simpler to a developer, but has deployment considerations. In 2010, code behind can run either in a farm solution, or via the sandbox user code service. However, code in the sandbox service sometimes may not run when the service is "busy". Your best bet is either: deploy code through central administration - if you have access, but then you trip up tip #4 if you haven't been using site columns, or don't use code behind and write your logic using only rules. You can find detailed InfoPath documentation for developers on MSDN (it may not look like much, but you have functions like get-SharePointServerRootUrl that are just gems hiding) 
   Plus, trust me you feel awesome when you can write complex logic using declarative XPath and no C# code. It's like saying yes I could cheat and just use C#, or I can be godlike and do it in XPath.
7. Copying pictures increases your resource size. The best way for a repeated picture is to include it as a resource, then use a picture button and set the image to your included resource. Unfortunately you can't set the image of a picture control.
8. Export form as Source files, and work with the manifest.xsf. While I'm pretty certain it is unsupported to tweak the view.xsl files manually by hand, at least you can now put all the component files within a source control and check what has changed using a simple text difference tool.
9. Learn how to call webservice with Rules. InfoPath is pretty dumb beyond what's within the form. Webservices gives you lots of capabilities but only if you know how to call them. E.g. how to interact with SharePoint users.
10. Don't use the "can't be blank" option, always create validation rules. When any validation rules fail, it puts the form into an invalid state and prevents any submit action. If you have them all defined as validation rules - you can add an additional condition that allows saving E.g. if ForceSave = "0" and "MyField" is empty 
    This gives you control over what happens when the user is trying to save, and allow you to disable the checking when you need to.

InfoPath Forms vs ASP.NET ASPX Forms

InfoPath Forms

Let’s begin by taking a look at InfoPath. InfoPath is a great tool for creating simple data-entry forms, and for retrieving data from a variety of data sources. In addition, it’s great when you need to submit data to a SharePoint form library for the purposes of leveraging a SharePoint workflow. Where InfoPath breaks down is when we need to submit data to other sources, or when we need to provide a rich user-interface with robust controls and data validation. Let’s take a look at some pros and cons of InfoPath:

Pros

• Great for submitting data to SharePoint or a SharePoint workflow
  Most of the time when we’re using electronic forms, it is to support a workflow process. As you [should] know, a SharePoint workflow runs for a specific list item, and data needed for the workflow needs to be entered into the fields for that particular list item in order for the workflow to see it. Because of this fact that the data actually needs to be a list item, InfoPath is a great choice, because you can effortless promote form fields as columns in your list, which the workflow can then use.
• Great for retrieving data InfoPath provides a very simple wizard interface for selecting a data source for data retrieval. You can easily select a web service, and XML document, or a SharePoint list and have that data appear in your form pretty easily. You can also connect to a SQL database and retrieve data from tables, views, or stored procedures.
• Great for simple end-user form development
  InfoPath is great for creating a simple form with a few fields and simple rules and simple data validation. I keep emphasizing simple because once you introduce complex business rules, data validation, conditional formatting, or complex data presentation that pushes the limitations of InfoPath, you will be forced to get very creative which often involves some sort of custom coding.
• Most of the time only requires SharePoint site permissions Unless you are creating a browser-enabled form with .NET code-behind, or your form requires Full Trust and uses the InfoPath client, it’s relatively easy to deploy a form to SharePoint. Simply publish the form to the desired form library and you’re good to go. However, as soon as you introduce .NET code in a browser-enabled form, you need to install and activate the form to Central Administration and activate the newly-created feature at the site collection level. You will need to have access to Central Administration and to the site collection in order to activate these features.

Cons

• Difficult to submit data to non-SharePoint data sources
  Like I mentioned, InfoPath is great for submitting data to a SharePoint form library. It is not so great for submitting the data to anything else. If your form is submitting data to a single (single being the operative word here), then you could potentially configure the form to submit directly to a table. However if the data needs scrubbed or manipulated, chances are you will need to submit the data via a stored procedure, which InfoPath cannot do. For this, you will be forced to develop a custom web service that accepts the data either field-by-field, or as a giant blob of XML that you have to parse through, which you then have to submit to the database by writing traditional ADO.NET code. Not too simple anymore, huh?
• Limited user-interface
  InfoPath allows you to create forms with a variety of standard controls, such as textboxes, date pickers, radio buttons, checkboxes, buttons, drop-down lists, repeating tables, etc.. Unfortunately, it is pretty much limited to those items (you get a few more with the rich client, but that’s beyond the scope of this post). You don’t have any type of tree view control, no multi-select list box, no tab control, no image buttons, and no grid view control. The lack of a grid view control is a deal breaker in many cases, because we often have to present long lists of data, and the built-in repeating table doesn’t support sorting, grouping, or paging. Yuck. Finally, there’s no way to add HTML or CSS to your form, meaning that it can’t inherit any SharePoint styles, and you’re limited to what you can design in the form. This frequently gives an inconsistent look and feel for a SharePoint process. Again, yuck.
• Difficult to secure sensitive data
  Assuming the InfoPath form is being submitted to a SharePoint form library, any data the form contains is inherently insecure. The form is just saved to the form library like any other document, except as an XML document. This means if your form contains social security numbers, salary information, or any other type of sensitive data, a user could download the XML file and open it in Notepad. Even if the data isn’t visible through InfoPath, the data is still stored in the form and can be viewed by any user that knows how to download.
• Difficult to integrate with Forms-Based Authentication
  Although browser-enabled forms will work with forms-based authentication, the useful username() function no longer works. This means that even if you’re logged into your SharePoint site as a valid FBA user, InfoPath will have no idea who you are.
• Not developer-friendly
  If you’ve made it this far in this post, you’ll have already read that while simple things are easy to accomplish in InfoPath, complicated things aren’t and often requires .NET code. While you can definitely add .NET code to a form, it’s not the same type of form coding a typical developer is used to. You have to parse XML to retrieve field values, you have to parse XML to set field values, and you’re still pretty much limited to the functionality that you have through the designer. You can just write more complex business rules and logic, you can’t make the form or the field controls behave any differently.
• Licensing Obviously your users need to be licensed for InfoPath Forms Services before they’re able to use it. Even if you have licenses for the InfoPath client, separate licenses are required for browser forms. If the users are internal and members of your domain, you must be licensed for InfoPath Forms Services, which is available either through the MOSS Enterprise CAL or the standalone InfoPath Forms Services CAL. If the forms are going to be available externally to non-domain users or anonymous users, then you must be licensed for either Office Forms Services for Internet Sites or be licensed for SharePoint for Internet Sites, which is the external connector that provides the ability for an unlimited number of users to access and use InfoPath through a browser.

ASP.NET ASPX Forms Creating ASP.NET ASPX forms offer the most in terms of flexibility, as you can do anything that you can do in a traditional ASP.NET web site, including HTML, CSS, JavaScript, and even AJAX. A lesser-known technique is integrating these pages into the SharePoint “shell” to give users a seamless experience. It doesn’t take much effort to have SharePoint host these pages and have the master page and styles applied to your custom forms. Let’s take a look at some pros and cons associated with ASP.NET forms:

Pros

• Great for submitting data to non-SharePoint data sources While InfoPath is great at submitting data to a SharePoint form library, ASP.NET forms are great for submitting data to everything else. You can easily write your ADO.NET code or whatever-you-like code to submit to your data source, and not have to worry about parsing a bunch of InfoPath XML first in order to pull out the values. It’s a lot less work to get the data into your data source.
• Great for providing a rich user interface Unlike InfoPath, you aren’t limited to a tiny set of field controls. You can use whatever an ASP.NET web site supports, including tree view, tab controls, grid views, AJAX – even Silverlight if you really really want. You can also provide any type of business rules and validation you like as well, including summaries, friendly pop ups, etc. Also, since the pages are inheriting the SharePoint styles and master page, your forms will automatically pick these styles up, and will also use the master page. This gives the appearance that they’re actually built-in SharePoint pages. It’s slick. There are plenty more options for developing a rich and clean user interface if you’re developing ASP.NET forms.
• Developer friendly This one’s a no-brainer. Obviously if you’re familiar with ASP.NET and .NET programming, creating data-entry forms are a cinch. There’s no learning curve with learning how to code an InfoPath form, and you don’t have to learn the ins and outs of the InfoPath object model. This opens up the development work to a wider audience of our developers, as not many have hands-on experience with writing .NET code behind an InfoPath form. In addition, should any future updates be required to the form or the code, finding resources on ASP.NET online or hiring someone with ASP.NET skills will not be a difficult task. It’s a widely practiced technology, and there are a ton of resources.
• Can provide secure means of sensitive data access
  Since no data is actually stored in the ASP.NET form, it provides a much more secure way of viewing sensitive data, as it will have to be retrieved and submitted to the database directly. A user can’t download an ASP.NET form and see the data like they can with an InfoPath form.
• Integrates well with Forms-Based Authentication
  By using an ASP.NET form in an FBA-enabled site, we are able to see the user that is currently logged in, unlike with an InfoPath form.
• Access to the SharePoint Object Model Since the ASP.NET forms are running under the context of the SharePoint site they’re accessed from, we can use the SharePoint Object Model to do whatever we wanted. We could very easily access SharePoint list or site data, user profile information, etc., and bind that information to controls on the form. To do this in InfoPath, you’d have to use the unfriendly out-of-the-box SharePoint web services, or write your own.
• Licensing Not required! There aren’t any licensing headaches when exposing ASP.NET forms to users, even externally. Obviously since they’re going to be integrated into SharePoint, you’ll have to have the appropriate licenses for that, but nothing specific to the forms themselves.

Cons

• Potential additional development overhead Obviously writing custom ASP.NET forms requires a competent ASP.NET developer, which may not always be available (though I’d argue that in order to develop some of the complex forms that we have had to do in the past – you will still need a very competent .NET developer). In addition, changes to simple business rules or data validation is more difficult to accomplish in ASP.NET than in an InfoPath form. If the form is simple and doesn’t require data going to SQL, then an end-user is probably better of just using InfoPath.
• Requires file system access on SharePoint server To deploy custom ASP.NET forms to SharePoint, they need to be placed onto each web front-end’s file system. In addition, the assembly must be deployed to the GAC or to the web site root’s BIN directory. Either way, the developer must have access to the file system, or to someone that has access to the file system.
• Not business-user friendly One good thing about InfoPath is that business users can even build simple forms. They will probably not be able to develop an ASP.NET form in .NET. If the form is truly that simple, then creating ASP.NET forms is probably overkill anyways, and InfoPath should be the recommended solution.

So, How Do I Choose? Great question! The answer should be easy -- do the simplest thing possible that will result in a clean solution. If you can implement the desired functionality quickly and painlessly in an InfoPath form, then by all means do that. If developing an InfoPath will actually be prohibitive to functionality and future maintainability, then consider building custom ASP.NET forms.

InfoPath - Hide Textbox

InfoPath Basics - Display text box if user selects Other using conditional formattingPromote two fields to a single SharePoint or Database column/field.

This article demonstrates how to configure an InfoPath form to display an optional text box for the user to enter a custom value if not available from the list of options. A separate field in the main data source of the InfoPath form will be used to store the value of the selected option, or the custom value if supplied by the user. Rules are set up to set the value of the separate field in the data source when an option is selected or when a custom value is entered into the text box. When submitting the form, the text field with either the value selected, or the optional text input entered if the user selects other can be promoted to a single SharePoint column, or database table instead of promoting both the option field and the text field containing the "Other" value if selected.

Conditional formatting is also used to hide the text box until the user selects "Other" from the list of options.

Process:Set up the Initial InfoPath Form

1. Design a new form template using InfoPath 2003 or 2007

2. From the Task Pane (CTRL+F1), open the Controls toolbar

3. Double click, or drag an Option Button control onto the default view of the form template. Enter the number of options required (remember to add an additional option for "Other").

> Note: In this example, the Option Button will have 5 options including "Other". The name of this field in the Main Data Source will be "Options"4. Right Click the first Option and select "Option Button Properties..."

5. Enter a Field Name for the field. Note: You only need to set the field name on one of the options for it to be applied to all.

6. Enter the value which will be used when this option is selected for the "Value when selected".

7. Press Ok

8. Repeat Step 6 for each option. Enter "Other" as the value when selected for the final option.

9. Add a text field control to the form template (main data source) for a user to enter a custom value if required.

Note: In this example this field will be called "Other".10. Add a separate text field to the form's Data Source only to store the selected value, or the value from the "Other" field by selecting "Add..." from the menu after right clicking the "myFields" group.

Note: For the purpose of this article, this field will be called "OptionSelected". This field does not need to be added to the form template. This field will contain the selected value from either the "Options" field or the custom value from the "Other" text field if required, and is explained further in the article.

Add Conditional Formatting to hide the "Other" text field when it is not required

11. Right Click on the "Other" text field control on the form template.

12. Select Conditional Formatting...

13. Press the "Add..." button to add a condition

14. Select the "Options" field created in step 3, "is not equal to" for the condition, and a text value of "Other" to test against (Select "Type text..." from the options).

15. Tick the "Hide this control" option for the formatting to be applied.

The "Other" text field will now only be visible when the user selects the "Other" option radio button.

Thursday, September 9, 2010

InfoPath Tip: Working with radio buttons and check boxes

1. This is how form with controls will look like.

Fig 1: Form

2. Add conditional formatting to Section 1 to hide it when Checkbox 1 is checked.

Fig 2: Conditional formatting for Section 1

3. Add conditional formatting to Section 2 to hide it when Checkbox 2 is checked.

4. Add rule to Option 1. By default, the value of Option button 1 is "1" and value of option button 2 is "2". Name rule "Open Section1" and set condition:

Fig 3: Set condition for Rule "Open Section1"

5. After setting the condition, click "Add Action" button to add action. In the "Field", select "Checkbox1" then click the "fx" button to add formula.

Fig 4: Add Action

6. Use "Insert Function" button to add "boolean" function or write it directly in the formula box. Click "Verify Formula" button to verify the formula and then click "OK".

Fig 5: Add Formula

7. You need to add three more rules. The rules are shared between the two radio buttons. Rules established for any of the buttons, both buttons. Add the second rule of "Close Section 2". Set the following condition:

Fig 6: Set condition for rule "Close Section 2"

Add action for this rule. Select "Checkbox1" in "Field" and leave the value blank. This will uncheck the "Checkbox1".

8. Add third rule "Open Section 2" to open the section 2. Condition set: Options is equal to "2" and add the action: "CheckBox2" has a value "Boolean (" true "). Use the technique described above to add formula. Remember, the formula of writing by hand is not set the Boolean value and will be considered as plain text in InfoPath.

9. Add fourth rule "Close Section 1". Add following condition:

Fig 7: Set condition for rule "Close Section 1"

Add following action:

Fig 8: Add action

Select "CheckBox1" in the "field" and uncheck the value. This disables the "CheckBox1". Remember that the sections are associated with those checkboxes. Checking CheckBox1 display section 1 and unchecking that hides in section 1. Similarly, CheckBox2 display control section 2 and unchecking that hides in section 2.

That's all. The point, in short, is that you must set the value of the box to "blank" to disable. Setting it to "False" is not uncheck.

InfoPath-Automatically change the first letter of a word/sentence to upper case

Problem

When an InfoPath user types in the text "example" or "this is really cool!", you would like this text to

automatically be changed into "Example" or "This is really cool!" when the user leaves the text field.

Solution

Use the concat(), substring(), translate(), and string-length() functions

in a formula to format the text field.

You can accomplish this functionality as follows:

Create a New Blank Form in InfoPath.

1. Add a Text Box control to the form.
   
2. Double-click on the text box control to open its Properties dialog box.
   
   
3. Click on the Insert Formula button behind the Default Value field.
   
4. Enter the following formula on the Insert Formula dialog box:
   concat(substring(translate(., "abcdefghijklmnopqrstuvwxyz", "ABCDEFGHIJKLMNOPQRSTUVWXYZ"), 1, 1), substring(., 2, string-length(.) - 1))
5. Click on the OK button when closing all open dialog boxes.

The first letter of a word or sentence typed into the text box should now automatically be converted into an upper case letter