Testing Debug Support
JBStrap applications can be remotely debugged using Java and debug tools in most Java IDEs. Testing and debugging JBStrap applications is the same as debugging and testing other web applications.
If you create an application using the recommended WildFly server and Eclipse , you can start debugging by starting WildFly in debug mode. Use port 8787 to access the application. JBStrap supports breakpoints and reading certain variable values.
To further help you test your application, the framework allows you to set individual component IDs. This ID is the HTML ID tag attribute. Since the application UI is dynamically built, the component IDs will be set automatically in run-time (provided that you have not set them beforehand). If an ID is automatically set, it cannot be guaranteed that components receive the same ID every time. This can make it hard or impossible to use debug software to debug the application. This is why you can set the IDs yourself, so you can run these automatic debugging programs to test your application. If you set the IDs yourself, they will not be overwritten. This way, components will have the same ID every time, so you can use an automated test. If you wish to use an automated test, you must ensure that no components share the same ID. If this does happen, the framework won’t be able to identify the component IDs. Certain events or modifications made after rendering the application may be attached to the wrong component. Always pay attention to component IDs!
Unique component IDs can only be set when creating the component. You cannot modify or add an ID after the component is created. The ID must always be the first parameter in the component constructor.
Testing client-side code
By default, the server-side is not notified about the exception, it is only logged on the client-side browser console.
The JBStrap framework also allows you to handle client-side JavaScript errors, or to send log messages to the server-side. Even though you can create applications without using JavaScript at all, you may still need to use it for your application. For example, you may want to create your own component, or want to use a third-party JavaScript library. The library may contain errors that cause exceptions when executed.
To allow developers to access these logs, JBStrap offers a JavaScript error handler solution. With this solution, the server-side is notified of any errors that happen on the client-side, thus allowing the developer to react and fix these issues. The error handler method receives the encountered exceptions as events. These events collect all relevant information about the exception and the client-side.
By default, the framework logs every error encountered in the server-side log. The log will contain the following information: 1) the error message, 2) the code snippet that triggered the error, 3) the exact location of the error, and 4) the corresponding stack trace.
Custom error handler
If you need/want to log different information about errors, you can create your own error handler method and register it in the framework. This custom error handler will be used instead of the default one.
In the following example, we will create an error handler method that logs the same information as the default one, with additional information, including information from the client.
To create a custom error handler, you must implement the JavaScriptErrorHandler interface. This interface has only one method that must be implemented: onJavaScriptError() . This method has one parameter, the encountered error event, through which you can access all the necessary information.
This error handler class must be registered in the framework. As soon as it is done, the handler will be operational. You can register the class using the JAVA_SCRIPT_ERROR_HANDLER parameter.
You can handle an error in any way you want to, you’re not limited to only using the server log. You can send a message to the user, store the information about the error to later evaluate it, etc.
You can also write messages from the server-side to the client-side log, helping the development and testing of custom JavaScript components:
Messages sent like this will be displayed in the client browser console with the specified type.