Custom Page Sections That Use a Custom UI Model

In the transition from ClickOnce to Web Shell, many existing page section types that were available in ClickOnce remain available in Web Shell. A page section that displayed a feature such as a report or data list requires little or no modifications to the page definition spec's XML code. Below is a section from the Constituent page that displays a data list.

Figure: A page that references a data list feature requires no modification to the page section type, even if the data list requires conversion.

Page sections that display data forms usually require a UI model for the data form, but the section metadata in the page spec does not require updates. See below for an example of section metadata within a page that refers to a data form. For more information about how pages display features, see Infinity Pages.

Figure: A page that references a data form feature requires no modification to the page section type, even if the data form requires conversion.

One page section type that could not automatically be carried over to Web Shell is the custom component section type. Page sections that reference a custom component must be modified. In addition, the feature referenced by the CustomComponent element requires conversion to a traditional data form that utilizes a UI Model, Report, or Custom UI Model.

Figure: Page sections that reference a custom component must be modified.

This is because unlike most other section types, a custom component feature is written entirely in WinForm code with no metadata describing its structure. Even data forms are not yet converted to UI model can still be displayed by auto-generating a UI from the data form's metadata, but of course this is impossible for a custom component. Until now, Blackbaud recommended converting custom component sections to view data form sections that could then be built using a UI model. This had one unfortunate side-effect, which was that in some cases a "dummy" stored procedure or CLR class had to be created when the data to display on the view form came from a source other than a direct database call. For instance, a custom component might make a call to a web service method and get its data in a complicated tree structure that might not even come from the database. Adding a stored procedure that returns no data or a CLR class that retrieves the data from the web service and converts it into a format that can be loaded into a UI model collection field just adds unnecessary overhead and is inefficient. To avoid this scenario and more closely mimic the spirit of the custom component section, support for a Custom UI Model section has now been added to page spec.