AX2118
This topic discusses design considerations for the source file for the Axiom form—the report file, template file, or other Axiom file that queries the data for the form and contains the form setup.
Querying data for the Axiom form
When you add components such as formatted grids or charts to an Axiom form, these components must be linked to data within the Axiom file. You can use any data query method to bring this data into your file, such as Axiom queries, data lookups, and Axiom functions. You can also "hard-code" data within a sheet as needed.
IMPORTANT: Whenever possible, Axiom queries and data lookups should be used instead of Axiom functions, for improved performance. GetData functions should be avoided unless there is no other way to return the required data for the form.
The data queries can be placed on any sheet in the file. Data is linked to Axiom form components by using data source tags, so it does not matter what the sheet name is, and whether or not it is set up on the default Control Sheet (although obviously you will need to do this if you want to use an Axiom query to obtain the data).
Any data that you want to display in the Axiom form must be queried or hard-coded in the file, and then flagged with the appropriate data source tags. For more information on tagging data in the file as data sources for Axiom form components, see Linking components to data.
Axiom query design considerations
When setting up Axiom queries within a form-enabled file, it is important to understand how these queries will be refreshed when the Axiom form is viewed. Queries should be configured so that they only run when it is necessary for them to run, to improve the performance of the form. For more information on this refresh behavior, see Update and save behavior for Axiom forms.
Refresh on open
When the Axiom form is opened, active Axiom queries are refreshed as follows:
- First, queries set to Refresh on Open are refreshed.
- Then, another refresh occurs that is equivalent to a manual refresh in an Axiom file (as if the user clicked the Refresh button). This means that all active Axiom queries that have Refresh on Manual Refresh enabled are run.
So if an active Axiom query has both of these refresh options enabled, it will be run twice when the file is initially opened. Generally speaking, refresh on open should only be enabled if refresh on manual refresh will be off when the file is initially opened (either hard-coded to off, or conditionally disabled using a formula).
Refresh on manual refresh
Any time the form is updated (either by an interactive component configured to Auto-Submit or by the user clicking a Button component), all active Axiom queries with Refresh on Manual Refresh enabled are run.
In most cases, it is not necessary to run a query this often, and doing so may significantly impact form performance. Ideally, if a query needs to be run after the form is opened, the refresh on manual refresh setting should be dynamically enabled and disabled using a formula. For example, the query might be configured to run or not depending on which component triggered the refresh (using the Triggering Component setting on the Form Control Sheet).
IMPORTANT: When troubleshooting an Axiom form, it is important to remember this refresh behavior. It may seem like something is not working, when in reality an Axiom query may be refreshing when it should not be, and overwriting changes that you have made to the source file.
Refresh after save
If you are saving data to the database from the form, the Refresh after save option can be used to run an Axiom query after this save occurs. For example, a user might input data into the form to be saved to the database, and then afterward you want this saved data to be available to form components such as a combo box or a formatted grid. Refreshing the query after the save-to-database will update these components with the relevant data.
Design for the Web Engine
When an end user views an Axiom form, a copy of the source file is opened by the Axiom Application Server using the Web spreadsheet engine. Therefore the source file cannot use any features that are not supported by this engine. Use of any incompatible spreadsheet features will either be ignored or will result in an error.
Any files configured for use as Axiom forms should follow the same spreadsheet design considerations as the Windows Client. For more information, see Windows Client design considerations for Axiom files.
Performance considerations
The design of the source file for the Axiom form should be as minimal as possible. The file should contain only those queries, formulas, and formatting that are necessary to drive the form data and functionality. If the file contains any content that is not necessary for the form, that content should be deleted.
When using remote server technology such as the Axiom Application Server, the Web spreadsheet engine is running on an application server. This engine consumes a certain amount of resources that would normally be used on the client machine. If you have 100 people looking at Axiom forms, your server will have 100 spreadsheets that it is processing on the server at the same time. The scalability of the server is far greater than the scalability of a client workstation, but the performance impact still should be considered. The faster your file is able to process, the more responsive the form experience will be.
Other design considerations
-
If the source file is a file group file, and you are using a calc method library with the file, then the first two rows of the sheet associated with the calc method library should be reserved for system-generated validation codes (template and calc method validation).
-
If you are designing form-enabled plan files, see also Designing plan files with embedded forms.
