There are a number of common problems that arise during renderer development. The first place to start is with the error messages that are reported.
When an error occurs in a renderer, the rendering of the page fails and an error page is displayed. During development, it is very useful to enable the option to display the stack trace of the exceptions in a HTML comment within the error page. This option is normally turned off in production, but can be enabled by setting the errorpage.stacktrace.output property to true in the ApplicationConfiguration.properties file (described in the Cúram Web Client Reference Manual). Then, then an error occurs, view the source of the HTML page to see the embedded stack trace.
The exceptions reported in the stack trace are often deeply nested. The top of the stack trace will usually show a series of nested exception messages before displaying the first trace. This first series of error messages is often sufficient to diagnose the problem. Each error message is reported with an error number. Look up the error number in the Cúram Web Client Error Message Guide to find out what the error means and what the possible causes may be. Do not ignore these errors or dismiss them or fail to follow the resolution steps in the documentationthese errors are rarely ever misleading.
The domain and style configurations are a common source of issues. Naming clashes or incorrect assumptions about the component order can cause problems. If a renderer simply does not seem to be invoked at all, check that it is correctly configured, that the configuration has the highest priority in the component order and that the application has been built after these changes have been made. Make sure, also, that the names of custom styles do not clash with existing style names.
A renderer plug-in class populates a DOM document fragment with the nodes that represent the HTML mark-up. At present, the CDEJ serializes the document fragment to XML text. This is compatible with the W3C XHTML 1.0 recommendation. However, some browsers are not fully compatible with XHTML and do not properly parse empty element tags, requiring instead separate opening and closing element tags with no body content. When an element node in the document fragment is serialized to XML text, an empty element tag is used when the element has no body content. To avoid parsing problems in the browser, it may be necessary to add some content to the body of the element to cause the serializer to generate separate opening and closing element tags. The simplest way to do this without affecting the presentation of that content is to add a comment node to the body of the element. The elements that cause the most problems are empty div elements and empty script elements. The browser may parse the page incorrectly, treating the empty element tag as an opening tag and nesting the following content incorrectly within that element. An indication that this has happened is when the view of the source for the HTML page in the browser does not match the view of the browser's DOM document (the parsed version of that source). The DOM document can be viewed with the web development tools available for most browsers. Adding a comment node to the empty element will resolve this issue.