Features that Require a Conversion to Web Shell

Any Feature with FormMetadata That Contains a FormUIComponent Element

For any of the following types of catalog items/specs that contain a FormUIComponent element, a UI Model must be generated and a WebUIComponent element defined:

• AddDataFormTemplateSpec

• EditDataFormTemplateSpec

• ViewDataFormTemplateSpec

• DataListSpec

• ReportSpec

• SearchListSpec

• SmartQuerySpec

• KpiSpec

• MergeTaskSpec

• SmartFieldSpec

• GlobalChangeSpec

• ConfigurationDataSpec

As an example, the following ViewDataFormTemplateSpec utilizes a FormUIComponent XML element. While this feature works in the ClickOnce Smart Client, the existence of FormUIComponent signifies that a conversion is necessary prior to viewing the feature in Web Shell.

After the spec is converted, a WebUIComponent tag replaces the old FormUIComponent tag.

At a high level, a conversion is accomplished by first generating a UI Model and replacing the FormUIComponent element with a WebUIComponent. Optionally, custom layout of user interface controls can be accomplished through an HTML layout file.

Note: For examples of creating a UI Model assembly project in Visual Studio and creating a UI Model, see Creating a UI Model Assembly NET Project.

Page Sections with CustomComponent Elements

In the transition from the Windows-based ClickOnce application to Web Shell, many existing feature types that are displayed within a page section that were available to a ClickOnce developer remained available in Web Shell. A page that refers to a feature such as a report or a data list required little to no modifications to the page.

One must note that a data form spec that contains a FormUIComponent element requires that the developer create a UI Model for the data form, but the section metadata in the page spec that references the data form does not need to be updated.

One feature type that could not automatically be carried over to Web Shell is the custom component. Unlike most other features that are displayed within a page section, a custom component is written entirely in Windows Forms code with no metadata describing its structure. If your custom page spec contains a CustomComponent XML element, you will need to convert the custom component to a Web Shell-supported feature.

Note: Sections that use a CustomComponent element are not supported in Web Shell, and must be converted to a supported section type such as a Data Form (AddDataFormTemplateSpec, EditDataFormTemplateSpec, ViewDataFormTemplateSpec) that utilizes a UI Model or a Custom UI Model (available as of the Blackbaud CRM 2.93 release).

Page Section Actions or Tasks with ExecuteCLRAction Elements

When developing for the ClickOnce Smart Client, a user may click an action (button or link) within an Infinity Page or select a Task within a Functional Area. Either the action or task can call upon a CLR action via an ExecuteCLRAction element within the page's action or task. A CLR action uses a ComponentIdentifier element to refer to a class that inherits from a known base class that provides certain methods like ExecuteAction() that the platform invokes when the action's button or link is clicked. Because CLR actions are written in .NET code and executed on the client with assumptions that certain features like Windows forms were at the author's disposal, CLR actions won't just work with Web Shell like pre-existing server-side code does.

Here is an example of an ExecuteCLRAction XML element within an Action on a page. This action is responsible for creating a windows scripting file that can be used to start a business process. This action uses a ComponentIdentifier element that will work within the ClickOnce Smart Client but is not supported in Web Shell. As a result, this action will not be displayed within the page in Web Shell.

Note: To see how to configure a page using a ExecuteCLRAction element on a page, see Step 6 of Building the Status Page exercise.

ComponentIdentifier elements within page spec or task spec are not supported in Web Shell, and must be converted to include a ScriptIdentifier element. In the example below, a ScriptIdentifier XML element is added to the action below the original ComponentIdentifier XML element. As a result, this action works in either the ClickOnce Smart Client or Web Shell.

Note: For more details, see Custom Actions.

FlashDashSpecs

Sections using a Dashboard element referencing a FlashDashSpec are not supported in Web Shell, and must be converted to a supported section type. Typically, this means either a ReportSpec or a set of UI Widgets.

Batches

Batches that include EventHandler elements must be converted to include corresponding WebEventHandler elements. Windows Forms-based custom dialog screens also require conversion using a Custom UI Model

Note: For more information on the Web Shell impact for batches, event handlers, and dialog screens, see Web Shell Event Handlers Overview and Creating Batch Dialog Screens.

Video: For information on changes and enhancements to the user experience for batches in the Web Shell user interface for Blackbaud CRM version 2.93, check out the following video.

Video: For information on changes and enhancements to the user experience for imports in the Web Shell user interface for Blackbaud CRM version 2.93, check out the following video.

Conclusion

In summary, custom features that rely on Windows Forms-based technology cannot be displayed by the Web Shell and must to be updated. The existence of a FormUIComponent XML element within a spec is a good way to confirm that the feature requires conversion. Page Sections that use a CustomComponent element are not supported in Web Shell. Neither are ExecuteCLRActions. Batches that include EventHandler elements and custom dialog screens must be converted to include WebEventHandler elements and Custom UI Models.