B. Settings

This appendix presents the framework's settings. They are stored in the settings.properties file from framework_home/com/devsphere/mapping/resources.

B.1. Error Logging

There are four flags that control the logging and the showing of the error messages. Their values may be 'yes' or 'no'.

[SHOW_APPLICATION_ERRORS]=yes

If the value of this flag is 'yes', the application errors are inserted within the produced form, xml or text documents. The 'yes' value is appropriate for development and testing. Set this flag to 'no' in a production environment.

[LOG_APPLICATION_ERRORS]=yes

If a logger object is passed to the mapping utilities and the value of this flag is 'yes' then the application errors are logged.

[SHOW_USER_ERRORS]=yes

If the value of this flag is 'yes', the user errors are inserted within the produced form, xml or text documents.

[LOG_USER_ERRORS]=no

If a logger object is passed to the mapping utilities and the value of this flag is 'yes' then the user errors are logged. The default value is 'no'.

You may want to turn this flag to 'yes' during the usability testing to see the frequent user errors. In the case of the FormUtils.formToBean() mapping utility, the user errors aren't logged when the form data object is an instance of the ServletFormData class and the HTTP method isn't POST. This way, you may use the formToBean() utility to fill the HTML form with default values when it is requested for the first time with GET. You still have to remove these user errors from the error table using HandlerUtils.removeUserErrors().

B.2. Removing Form Action

[AUTO_REMOVE_FORM_ACTION]=yes

The ACTION attribute of the HTML forms must not be used if you apply the application model presented in one of the previous chapters. The same handler sends the HTML form and receives the form data.

By default, the ACTION attribute of the HTML forms is removed automatically so that you can use existent HTML forms without having to modify them.

If an HTML page contains a few forms whose data must be handled by different server-side scripts, you have to set this flag to 'no'.

B.3. Validating XML

[INCLUDE_DTD]=yes
[VALIDATE_XML]=yes

By default a DTD is included within the produced XML documents and the XML content is validated by the XML parser. This is recommended for the development and testing phases. In a production environment you may set these two flags to false in order to increase the performance of the application.

Note: If you set [INCLUDE_DTD] to 'no', the saved documents will not contain a DOCTYPE declaration. If you keep [VALIDATE_XML] to 'yes', a parsing error will occur because of the missing DTD.

B.4. Setup Utility

The setup utility helps you to configure the framework. The main screen allows you to input the serial number and the key. The framework may not be used without this information. The first button (Save Key) saves the serial number and the key to the key.properties file from framework_home/com/devsphere/mapping/resources. The next two buttons open configuration dialogs.

The "Classpath" dialog computes the string that must be added to CLASSPATH. The checkbox buttons at the bottom of the window allow you to control which parts of the product are included in CLASSPATH. The "Copy to Clipboard" button copies the computed CLASSPATH to the system clipboard.

The "Settings" dialog allows you to view or change the framework's settings, which were explained in this appendix. In addition, there is a combo box that contains three predefined profiles: "Development", "Usability Testing" and "Production". You must click the "Save Settings" button and restart the application that uses the framework so that the new settings become effective.