ShowTable of Contents
Order of Builder Calls in a Client Model
- Theme. Theme builder call(s) or imported model containing common theme(s) should be first.
- Client Application. The Client Application builder call should be after the theme, because It depends on the theme. It should not typically be imported from another model. The first Client Application is included in the application, and all others are ignored.
- Service Consumer. If the model has a Service Consumer builder call, it must be after the Client Application, because the Service Consumer uses slightly different functionality for a client-side application. Common Service Consumers can be included in an imported model.
Sensitive Data Visibility and Hiding Fields
- Hide sensitive fields via server side transforms. For client applications, all fields of a client variable are sent to the client, even fields that are not displayed, such as fields that are hidden via Data Field Settings. This is a basic difference between server applications and client applications. For example, if fields containing sensitive values are hidden via Data Field Settings, a server application filters these fields during JSP processing on the server. But a client application does not filter these fields until the page is processed on the client. If an application has sensitive values that should not be sent to the client, then the application should explicitly transform or filter the sensitive values on the server before the results variable is sent to the client via the consumer. This could be done, for example, in a service provider model.
Using Imported Client Models
- All Pages. Builder calls in an imported client model should not refer to "All Pages". The problem with this approach is that the builder call will also be applied to the aggregator page and any pages in other imported models. When using Data Field Settings, check each individual page instead of "All Pages". For other builders with a Page Location, use the Advanced option to specify each page instead of specifying All Pages.
- Themes. Themes should typically be included in a separate model. This "theme" model can then be imported by the top-level model and each lower-level model. In each case, the Imported Model builder call should be set to "Import Once". The advantage to this approach is that each lower-level model can be run independently of the top-level model, and still use the correct theme.
- Initial Client Action. The Client Application in the top-level model should typically specify an initial client action. This can be as simple as specifying the initial page to be displayed. Or it may require a Client Action List that initializes data and displays a page. In either case, specifying the initial client action in the top-level model avoids the issue of imported models that define a default initial client action.
- Aggregator Page. Referencing the aggregator page of a client-side application is always discouraged. An imported model with references to the aggregator page will usually result in an error or warning, because that page is not included in the application. A client-side application can only have one aggregator page, and will use the one from the top-level model.
- Navigating Between Models. If navigation is required from the imported model to the top-level model, the "back" button should be defined in the top-level model. This allows the button to be placed at a page location in the lower-level model and navigate using an action or page in the top-level model.
- Profiling. Imported models should "use parent profiling". This allows the top-level model to be run with the applied profiles from the imported models.