The Servoy framework has been extended to provide the enterprise level functionality required to meet our application requirements. This has been implemented with custom code mostly using the available Servoy API and address functionality which we consider "a must" for a modern enterprise application but are not available out-of-the-box from Servoy. In addition, Servoy has added specific functionality to meet our requirements. All custom features have consistent behavior and identical programming model for both the Smart and Web client. Some of the features are implemented using custom plugins which extend the functionality beyond the available Servoy API.
SecurityEnd-user customizable, role-based permission configuration and authorization. End-user administrators can define custom permission sets which are not limited only to application
UI elements and database table operations but support business logic methods as well. The re-usable permission sets can be used for nested user groups.
User password compliance and management functionality. By default, the Servoy security options provide the basic functionality. Our application framework extends it to include complete password compliance and management functionality (for example, requirements for password complexity, minimum length, expiration, and previous password history).
Robust user authentication with security events auditing and user account lock-outs. This provides options for security events auditing or features to deter brute-force attacks to the Servoy authentication mechanism. Our application framework implements these features by providing options for administrators to use security auditing and to lock-out user accounts for a period of time after a number of failed logon attempts.
DeploymentCustom database deployment and maintenance tool. This is required in order to create the appropriate database schema with correct column datatypes, applicable unique and clustered indexes, database constraints, etc. This extends the standard Servoy database deployment functionality to require that specific columns must be of type money or fixed precision decimals. It differentiates that some text columns should use multi-byte datatype while others should use a single-byte. It also provides for defining database indexes or database check constraints.
It allows custom deployment of system data that extends the file-size limitations of the standard Servoy mechanism.
Application UIEnd-user grid customization at run-time. The customization added a feature to allow end-users to view a list of available grid columns and specify which ones should be visible. The customized layouts can be persisted and automatically restored in subsequent client sessions. This adds to the standard Servoy interface that allows end-users to rearrange the column order.
Multi-column grid sorting in Web Client. End-users can sort grids by multiple columns at runtime on both the Smart and Web client.
Modal dialogs with blocking calls which work consistently in Smart and Web Client. The Servoy Web Client was enhanced to allow modal dialogs to block call chain processing using the Rhino Continuations procedure to provide a consistent programming model for the modal dialogs for the Smart and Web Client.
Multi-instance form management. Our application allows end-users to display simultaneously multiple instances of the same form application form. Our custom form instance management allows "clones" of the default forms to be created as needed when the client code requests a form by name. This extends the default Servoy functionality that works only with 1 default form instance.
Application form UI customization by end-users. Our requirement for end-user administrators to be able to customize the application form layouts required that we add to the default layout manager control/option. As a result, our application framework supports this functionality and allows end-users to customize the application UI. The customized forms do not simply "hide" elements which are made invisible but actually modify the form "blueprint". This reduces the size of the generated client forms.
Automatic generation of application forms UI using application meta-data. Most of the application end-user UI is automatically generated using application meta-data and end-user defined layout. This ensures UI consistency, provides clean separation between the application business logic and UI, reduces the application code maintenance overhead and at the same time provides a customized user interface tailored to each client’s specific needs. The UI elements generation is driven not only by the datatypes of the table columns or form-level dataproviders (which is the standard Servoy implementation), but uses also the foreign-key relations and additional application settings to automatically generate lookups (type-ahead controls) and combo-boxes with the appropriate valuelists.
Consistent application shell with identical functionality in both the Smart and Web client. This customization harmonized the Smart and Web clients. Our custom application shell, including the application menu and toolbar, is consistent for both types of clients. We have developed custom toolbars and form navigators/side-bars which work identically in Smart and Web clients.
Generic, user-friendly search UI. This modifies the default search options in Servoy that requires end-users to enter special search operators along with the search values (for example: ^, ||, !, .. and # - in addition, these special characters need to be "escaped" if they are to be included in the actual search value. This particularly simplified the date & time search operations). Foreign-key fields visualized with lookups that have different display and real values also require special handling in search operations (for example: in a transaction form which has a customer lookup field, search for transaction records which have customers with names starting with "A"). Our custom search UI makes the process of finding data extremely easy and intuitive for end-users and at the same time is implemented in a generic way which is reused throughout the whole application.
User-friendly styling of field states. Our requirement to provide visual indication for focused and read-only fields on the screen along with support for dynamic read-only fields required customization for both the web and smart clients.
Application Business Logic ImplementationSupport for nested calls to database transaction methods. Database transactions are a core requirement for enterprise applications. In order to reuse as much as possible of our business logic code, our calls to the business logic methods require a "nested" structure. (one method, calling a second one which in turn calls a third one, etc. but the second and the third method can be used just by themselves as well). Support was added for nested business logic methods for database transactions to allow nested calls to beginTransaction/commitTransaction/rollbackTransaction to be used.
Application form record state management when working with disabled "autoSave" mode. Our application works with disabled "autoSave" option. This was enhanced to provide a generic way to handle records entered in an "edit mode" for the first time and when it leaves the "edit mode" (the changes are either saved or canceled). Our application framework implements functionality to provide consistent and reusable record state management for the application forms.
Independent batches of work within the same client session. The framework was enhanced to allow end-users to make data changes in different contexts/screens at the same time and save those changes to the database as separate "batches of work" (for example, have two different screens open at the same time on two different tabs and allow users to change data in both of them; each screen has an independent Save option which allows the changes in one of the screens to be saved in the database while the other changes are still "pending"). To support this, database transactions are used because usually the context changes involve more than a single table.
Additional Application Business Logic Features:
- Custom data defaults
- File attachments
- User-defined data templates for extending the standard business entities.
- Out-of-context ("on-the-fly") creation and editing of records
- Generic lookup dialog extending the standard TYPEAHEAD control.
- User tasks framework
- Background processing framework
- Process Engine
- Telephone number validation and formatting using the Google's phone number handling library
- Custom data import of Excel and CSV files which is supported on the Smart and Web client.
- Generic foundset-based file export and import.
ReportingCustom plugin to manipulate JasperReport templates allowing usage of the same report templates against different types of databases. An option was added to support multiple types of databases (for example, MS SQL Server, Oracle, Postgre SQL and DB2) with the same report layout files (.jrxml). This required an option to "inject" the report queries in the layout templates at runtime.
Using our custom plugin, the application dynamically provides the necessary query (in the appropriate SQL-dialect depending on the database in use) to the report layout file modifying the XML content using the JasperReport API. This allows for a single library of reports which can be used against any of the supported databases and the report queries can use the native database query language and options.
Additional Report Features:
- Customizable dashboards for graphical data presentation using various chart types and drill down functionality.
- Generic export of grid and form data to various file formats.
- Custom financial reports with extensive configuration options.