Designing for BrightWeb
Contents Hide
When designing web applications, there are a number of considerations that must be made regarding the platform, due to the nature of web connections, application states and data management. The following chapter lists these considerations that must be made, and not only apply to applications developed for BrightWeb in BrightBuilder, but conceptually apply to web applications as a whole, and should be considered when determining if web is the most suitable solution for the end user/problem domain.
Always Connected Environment
When designing a web application, the client device must always be connected to the server. Any disconnects or issues with the connection will result in the application being inaccessible, and thus it is vital to consider the devices and environment before determining if the web platform is feasible as a mobility solution.
Data via Server Direct Access
Data is directly read from and written to the server in web mode - similar to the 'Server Direct Access' database setting for BrightForms on Windows platforms. Therefore, as all database operations is on live data, there is no concept of synchronisation in BrightWeb as there is in BrightForms, and the BSP tables of projects must be mapped to server tables accordingly. Furthermore, the database in the BrightServer configuration be exposed as a 'Server Data Source' for access via BrightWeb.
Since the data being viewed is on the server database, the data segmentation should be planned carefully. For instance an occasionally connected rich BrightForms application could have a subset of a customer list synchronised from server. Naturally the local application does not have to further filter the customer list data when displaying it on various forms. If however this application is ported to a web solution, then the same application would be displaying the entire customer list in the web mode. In summary, it is important to review these aspects of the application logic to ensure the user has only access to the data needed.
Also, due to the nature of live and constantly changing data, it may be necessary to have completed/incomplete states reflected in the data model. If complex data dependencies and referencing needs to be made on static data, data staging on the server for the web mobility solution may also need to be considered. A simple example would be an order taking process. In a web application as the order is being created, the order header and items data must be processed only when the order is marked as complete and submitted by the web user. This would mean a staging data structures needs to be maintained by the web application, and a submit process must be defined so that the backend systems processes consume only the submitted data.
Combo Boxes in Web
Combo boxes are not supported by the web platform, and will function as the drop-down variation if set. It is advised to use drop-down and/or edit controls and combine the two via expressions or selection forms, as the functionality of both cannot exist in a single control on the web platform.
Form Loading and Application Usability
When screen changes need to be rendered to the client device, or the client needs to send form data to be processed to the server, the form will be loaded on the client side. This can be a disruptive experience for the user if they are not consciously driving such changes. Therefore, when developing web solutions, it is important to consider data to and from the server - whether it is consciously user driven or non-user driven. For example, screen changes using timers, or action events via edit control text changes will cause frequent and uncontrollable reloading of the form for the user, and should be avoided when developing on the web platform.
In these scenarios, a directly user driven event such as having the data entered and sent to the server via, for instance, a button is preferred, improving usability as the user has more control over state changes in the web application. This ultimately also makes the application more suited to web standards and practices, and thus is important to consider when creating or adapting a solution for the web platform.
User Navigation
The browser navigation buttons are not to be used for BrightWeb applications.
Forms and user workflow should be considered entirely within the application, by using the provided navigation buttons on the BrightWeb Toolbar, or by providing custom functionality through form controls. Conversely, user options may also be limited by developers if necessary; all navigation links on the BrightWeb toolbar - close, home and logout may be disabled via each form's properties.
Form State Management
A form is considered initialised in BrightWeb once it reaches a state where it may be transmitted to accept user input, and this may then be transmitted back once interacted with by them. In this state, BrightWeb can navigate away from and resume the state of a form freely upon user input. This design is to ensure efficient transmission of forms to end users of the application, and minimised server loads when running it.
However, forms' pre-open and post-close expressions are not user-driven, and handled by the server. The state of forms when these expressions are executing are thus not tracked; forms may not be suspended or resumed from within these points. This becomes an issue when opening and closing forms in BrightWeb. While BrightForms on Windows and Android may open and close forms freely at any part of the form, BrightWeb is more limited, only being able to open forms once others are fully opened, and close only if the return form is already open. Operations outside this period will cause an error.
Consider the following cases:
In the first diagram, Form B opens when the parent Form A closes, cannot return to the form expression, but also cannot reach Form A's parent.
In the second diagram, Form B opens at some stage when Form A does. As Form A hasn't fully instantiated in web, the restore state after B closes is undefined.
While not containing "Action - Open" or "Action - Close" properties, a message box also serves as an interrupt to a form, and thus the same applies.
The solution to this state issue is to always have a parent control form which is returned to controls both forms, as shown below. In the case of message boxes, having the message, status and/or options on the screen without calling the Form.MessageBox() method is also a viable option to address this issue.
In the first diagram, Form B will be opened by a parent form, instead of Form A, and this is done after Form A fully closes. Form A may need to pass variables to its parent to support this pattern.
In the second diagram, Form B will be opened before Form A, and once completed and closed, Form A will open. Any checks originally made in Form A must be made in its parent form to support this pattern.
In short,
Do NOT open a form or message box before another (its parent, its parent's parent) fully opens!
Instead, adjust the opening to be directly user driven, rather than operating automatically via "Action - Open" and "Action - Close" expressions.
Following this rule will ensure that developing web solutions with the BrightXpress mobility suite may be executed smoothly and effectively.
Work Flow and Timeout Management
The server session timeout determines the duration users may idle on the server before having to log into their application again. By default, this is set to 300 seconds, or 5 minutes. If the user is inactive for this period of time, their session will be terminated, and any reload or operation they do after this timeout will direct them to the login screen.
For BrightWeb applications, 15 (fifteen) minutes is the typical recommended time to set the user timeout period. If it is found that users are typically exceeding this idling limit, the workflow of the user within the application may need to be reconsidered.
It is important to note that each user session consumes precious server resources such as memory, database connections etc. This means that the more sessions on the server, the more system resources are required. Therefore having long session timeouts can result in more server resources than needed, slowing the server performance.
Long session timeouts are also a security risk where the user devices are unattended more than needed. They can lead to unauthorised access to user applications and hence the business data.
Application Release
BrightWeb users are always presented with the latest application release upon logon. If however a new version is assigned to the user who has already logged, the user will access the new version after a new login. When the web user logs on, BrightWeb checks the application and release number that is assigned to the user, then it loads the required application version and services the client requests.
Development of applications is conducted directly on the server by deploying and releasing iterations of the project to users. As such, it is suggested to have a development server for designing and testing the application itself, then to release the application for release on a different server for the end users.
Application Logging
BrightForms on Windows and Android platforms provide log files for system and application events. Similarly BrightWeb provides the same facility through the server log files by logging the system and application events depending on the trace log level. The Trace object will also output to the server log file, with the trace level respective to the methods called.
Logging enables users to observe events and issues in real time. In order to isolate and debug issues, BrightWeb servers may be needed to be put into the Debug mode. This would however slow the server drastically and should be used only if it is absolutely necessary. Thus it is advised to have methods to recreate issues in separate server environments such as development and test where they may be isolated and repeatable, rather than relying on the main production server.
Web specific routines
Where differences in terms user interface, business logic, form navigation etc. need to be made between Windows, Android and Web platforms, the System.GetOS() method may be used to determine what platform the application is running in. For example:
IF(System.GetOS() == OS_WEB)
{
// Web behaviour
}
ELSE
{
// occasionally connected mode behaviour
}
When launching the main form of the application, if Windows or Android specific login pages are no longer needed, the project property 'Web Main Form Name' may also be specified.
By retrieving the OS, any web specific routines may be included, with the business logic remaining intact, and thus a unified solution may be attained across all platforms.
BrightServer Branding
BrightServer's default login page may be customised via the BrightBuilder or the BrightWeb management console to display customised logos and text strings to users when they access the BrightServer URL. This may be done via the Branding node of the BrightServer. For more information, please refer to the BrightServer > Configuring BrightServer > Server Branding chapter of the Bright Software User Manual.
