Category Archives: InfoPath / Forms Development

Conclusions On Forms Services Development

Using InfoPath 2007 and InfoPath Forms Services within a SharePoint environment is a powerful option to take legacy paper-based form processes and convert them to powerful electronic data entry mechanisms that streamline overall business process while easing overall development efforts. Although there are methods to generate forms for use within SharePoint by developing custom WebParts that contain the relevant .NET controls for data capture and event handling to fetch or submit data to a variety of a data sources, the inherent InfoPath development capabilities make it a lucrative option for form development tasks.

Forms Services solves one of the largest issues that was present in environments trying to leverage a hybrid InfoPath and SharePoint solution, where users attempting to access InfoPath forms required the InfoPath Smart Client to be installed on the requesting machine in order to input relevant data. The introduction of the XmlFormView control provided by InfoPath Forms Services allows HTML rendering of InfoPath forms either within SharePoint WebPart pages or using a custom SharePoint WebPart, allowing InfoPath forms to be accessed from any machine, regardless of available form software.

Using Design Once programming principles split object models aren’t necessary for developing forms that will render in both the InfoPath Smart Client as well as casting the form to a browser, programming intuitive forms that are environment agnostic is a straightforward task. Benefiting from integration with the System.Xml namespace, integration with powerful IDE’s such as VSTA, many familiar programming concepts and semantics are available when developing tailored, impressive electronic forms targeting the Forms Services platform.

Several types of data sources can be assimilated into the InfoPath Forms environment when using InfoPath 2007, such as Web Services or Databases, all of which can be customized further through the use of managed code. Using the inherent Data Connection Libraries that SharePoint provides allows the option to store UDC’s that are being used throughout a Forms environment to be managed in one central location and called by forms at run-time, allowing the backend connection plumbing to be hidden from users that are consuming various connection types from InfoPath.

Using the Events Manager allows the capturing of three types of events, Form events, Xml events, and Control events. Using custom code to manage these events allows the granular options which allow you to heavily control user interaction with the form in regards to event trapping and management. Calling these events can be done through the design surface control menu in the InfoPath Forms Designer, or by registering the event capturing the InternalStartup() method.

Using InfoPath Forms Services requires some consideration in the terms of security and deployment. There are three main security settings for forms, full-trust, domain, and restricted, each with their own implications that must be considered. Most importantly, administrators must approve forms that are tapping into backend business logic since they require full-trust. When deploying forms, there are certain steps that must be followed to successfully deploy a form, from initial publishing of the form to activating the form to make it available to various site collections.

Forms Services is one of the most powerful features that has been released based off the SharePoint platform. Because forms build the interface to enterprise data operations, automating forms through electronics process greatly increases overall organizational operations efficiency and procures an environment that can highlight end-user interaction into how the forms development process should develop and grow.

Share

Developing A Form WebPart – Part 5 – Wiring The Submission Event

The last portion required for the Form WebPart is getting the actual data into the database by wiring a submission event to the save button declared previously, easily accomplished by calling a stored procedure to accomplish the task. By pursing the option of using stored procedures, the option exists whether to use the native CLR stored procedures or to use a standard T-SQL stored procedures.

Since the submission of the data is relatively straightforward, the Forms WebPart uses three small classes to build extendable business logic. Using a base class allows the inclusion of code to enhance the Forms WebPart, such as allowing users management actions (editing or deleting entered information in the ID table, for instance). Accomplishing this is best performed by building out a concrete, abstract class to supply as the base class for the remaining database layer child, supplementary classes. An interface to facilitate this is not advisable since additional class versioning is much easier with abstract classes and virtual methods tend to provide a slight performance benefit in terms of performance execution. In the concrete IDRow_Base class, there are several actions that will be defined. The constructor will initialize a new instance of the IDRow_Base class, the ID property assessors will be set in order to get or set the ID column value, and using a System.Text.Stringbuilder there will be a string representation of the instance returned.

Here is the code for the abstract base class for the ID row table:

[csharp]

        public abstract class IDRow_Base
        {
            private string _id;
            public IDRow_Base()
            {
            }
            public string ID
            {
                get { return _id; }
                set { _id = value; }
            }
            public override string ToString()
            {
                System.Text.StringBuilder dynStr = new System.Text.StringBuilder(GetType().Name);
                dynStr.Append(‘:’);
                dynStr.Append(”  ID=”);
                dynStr.Append(ID);
                return dynStr.ToString();
            }
        }

[/csharp]

Once you have defined the abstract class, it can be used to initialize a new instance of the IDrow base class, which is done by specifying the empty class constructor which inherits the IDRow_Base class. This allows the representation of an ID record object which is passed as a parameter to the actual insert method.

Here is the code for base class record representation:

[csharp]
        public class IDRow : IDRow_Base
        {
            public IDRow()
            {
            }
        }

[/csharp]

There are several ways to accomplish the submission of the data into the backend database from the Form WebPart. One way to accomplish the insertion of the records would be to call a stored procedure by passing the stored procedure name into the CreateCommand method that takes either a string of T-SQL or a stored procedure name (this is shown in the following code). The easiest way is to just call a SQL script that contains the T-SQL insert method.

Here is the code for a record insert method by calling a stored procedure:

[csharp]
        internal IDbCommand CreateCommand(string sqlText, bool procedure)
        {
            IDbCommand cmd = _connection.CreateCommand();
            cmd.CommandText = sqlText;
            cmd.Transaction = _transaction;
            if (procedure)
                cmd.CommandType = CommandType.StoredProcedure;
            return cmd;
        }
        public virtual void Insert(IDRow value)
        {
            IDbCommand cmd = _db.CreateCommand(“dbo._ID_Insert”, true);
            AddParameter(cmd, “ID”, value.ID);
            cmd.ExecuteNonQuery();
        }

[/csharp]

Share

Developing A Form WebPart – Part 4 – Setup the Validation Controls

The data that is being submitted with the Forms WebPart requires validation before it is committed to the database in order to maintain integrity of the information being stored. Doing validation with WebParts typically occurs in two main ways. One can choose to script a separate method in order to validate the entry by using an option like ServerValidateEventArgs.IsValid against the argument, or the inherent validation controls that ASP.NET 2.0 provides can be called in order to validate the information. Considering software architecture concerns and code bloat as a factor, it is typically preferable to use the inherent ASP.NET 2.0 validation options, which will also allow the extension of the validation being used to be assimilated by sister validation controls such as ValidationSummary.

Be aware that when using the inherent validation controls your WebPart will become subject to using client side script as the validation will depend on it. When leveraging the RequiredValidation controls in a WebPart, it will append some JavaScript to the form page on which it is added by calling ValidatorOnWSubmit(). There are known issues when trying to use multiple Form WebParts that use the inherent validation controls. SharePoint will always call the first validation control even when validating a secondary control on the page.

Here, you’re validating a numeric entry manually with a custom method.

[csharp]

            public void ValidateNumeric(object source, ServerValidateEventArgs args)
            {
                try
                {
                    Decimal temp = Decimal.Parse(args.Value);
                    args.IsValid = true;
                }
                catch
                {
                    args.IsValid = false;
                }
            }

[/csharp]

And now, validate input using the native validation controls.

[csharp]

            protected override void CreateChildControls()
            {
                base.CreateChildControls();
                textTextBox = new TextBox();
                textTextBox.ID = “textTextBox”;
                Controls.Add(textTextBox);
                rfvFieldValidator = new rfvFieldValidator();
                rfvFieldValidator.ControlToValidate = “textTextBox”;
                Controls.Add(rfvFieldValidator);
            }

[/csharp]

Share