FOEX Live Editing with Websockets
In this release we are introducing a new addon to introduce live editing capability of the grid, tree grid, and editable list views using websockets. You will be able to see realtime changes and a realtime visualization of other users modifying data in the same view of data you are viewing. Just like you can with Google spreadsheets.
Tree Grid Demo
List View Demo
Notify Other Regions Demo
This is achieved using websockets and Node.js. Setup is simple as checking a checkbox under the options within your region attributes. You can configure an unlimited amount of regions within your application as well as broadcast between regions that share similar data.
You have several states the live editing can be in i.e. Online, Paused, and Offline
There are a number of predefined defaults which can be customized as per the following settings:
You can enable row or cell level locking when users are editing grid records e.g.
You can even (optionally) see who also editing the grid and even see their recent change history and what they actually changed e.g.
Additionally we provide a PLSQL API to allow you to send messages directly from the database via a REST call. You would want to do this in situations where the data is being changed in some batch processing code, or “Execute PLSQL Code” dynamic actions separate from the region’s CRUD requests & refresh row actions. Simply provide a cursor of the changed records you want to broadcast and they will be sent to the websocket server which will message all users registered on the channel(s) you specify. Remember to make sure that your query columns match the same column aliases as your grid/tree/list SQL query columns. Here’s a basic example:
DECLARE l_cursor SYS_REFCURSOR; l_oid FX_T_DEMO_COMPANY.OID%TYPE; BEGIN l_oid := v('P1_OID'); OPEN l_cursor FOR SELECT OID , COMPANY_NAME , STREET_ADDRESS , POSTAL_CODE , CTY_OID , PHONE_NO , EMAIL FROM FX_T_DEMO_COMPANY WHERE OID = l_oid; fx_p_websocket_notify.data_notification ( p_static_ids => 'CELL_EDIT_GRID,ROW_EDIT_GRID' -- you can update multiple regions , p_cursor => l_cursor , p_operation => 'update' -- create, update, delete ); END; /
FOEX Live Editing has been designed with performance in mind. There is no additional overhead on the database by enabling this functionality. All data relayed over the websocket is done securely by the browsers after the data has returned from the server. For example: when an update is performed on a Grid, the changes are made in the database, the rows are re-queried and sent back to the browser, and then the browser sends this data to the websocket server to be broadcast to all other users listening on the region’s private channel. There are no AJAX calls back to the database to grab any data, even for checksums etc. as this is all provided in the response from the grid update. This applies to all CRUD operations on all region types, forms, grids, tree grids, and editable list views.
For the PLSQL API we use a REST call that allows the database to directly broadcast from one record up to thousands of records in a single call using a SYS_REFCURSOR type.
For the visualization of the changes within the regions, we only apply highlighting to the records the user is currently viewing. We do not apply any highlighting to records that are not in view and must be scrolled to. This maintains optimal browser performance since there’s no point showing any highlighting or animation of changes the user can’t see.
For the websocket server itself we went for a high performance lean implementation using the npm ws package. as opposed to using something heavier like Socket.io. This gives us greater control and flexibility for how we designed the registration & communication system.
You can use SSL mode for both the Websocket and REST endpoint or HTTP during development. We use token based encryption to secure connection to the web sockets and regions register what columns users are allowed to see to ensure that data or parts of data are not broadcast to users who should not see it. Note: the column list is encrypted to avoid any client side tampering.
The encrypted data uses the AES 256-bit algorithm with Cipher Block Chaining and PKCS #5 padding.
For some businesses the difference between knowing something now vs in 1 minute from now can have a huge impact. It can save lives, it can give you a competitive advantage, it can make you more money. This is what you get with FOEX Live, seeing your data changes in realtime and being able to immediately respond and make decisions based on these changes.
Debounce & Throttle Dynamic Actions
In this release we are adding additional dynamic actions to provide some missing functionality in APEX, which is the ability to deal with actions that fire too frequently e.g. you probably don’t want your TRUE actions to fire until a keyup event (when the user is typing) until they have stopped typing for say 1 second. These new actions we are adding are Debounce & Throttle.
What’s the difference between Debounce and Throttle?
Debouncing enforces that a function not be called again until a certain amount of time has passed without it being called. As in “execute this action only if 500 milliseconds have passed without it being called.”
Throttling enforces a maximum number of times a function can be called over time. As in “execute this action at most once every 500 milliseconds.”
The interesting thing about these actions is that they only apply to proceeding actions, so you can define actions before them that will fire every time the event fires, thus giving you much more flexibility. Note: the only requirement when using these actions is, you must set “Wait For Result” to “Yes”
We have introduced an improvement to both the Timer and Message Box plugins to allow developers to easily include an inactivity timeout warning. The Timer plugin has a new inactivity timer option which will be triggered when the user has not moved their mouse or pressed a key for X many seconds. Here’s a simple example where we will reload the page after detecting inactivity.
As you can see in the image we provide a progress indicator with a timeout message. The OK button is included to allow the user to prevent the default action from occurring e.g. page reload, session timeout etc. Since the “Message Box” allows you to define PLSQL you can use this setting in conjunction with the application Idle timeout to prevent the APEX session from timing out as well. Or you could use the “No/Cancel/Timeout” PLSQL to log the user out e.g.
APEX 19.2 Support
With this release of FOEX we now support APEX 19.2. You will be able to take advantage of all the new features APEX provides e.g.
- Faceted Search
- New Popup List of Values
- REST Enabled Interactive Grid
- New Dark Mode Theme Style
- Team Development Improvements
- Plus many other improvements
Thanks to the continued use of FOEX from a growing customer base we receive requests for enhancements and improvements. Whilst we can’t implement every request we receive (for different reasons) the following improvements have been introduced in this release:
- New expand/collapse rows functionality for tree/tree grids
- Deselect capability in Single Grid Row Selection
- Allow typing in the grid combo input
- A new declarative option to “Save all Records” in the grid
- New actions to suspend/resume auto save on grids, trees, and lists
- Include changes made to grid rows in the POST Processing Procedure hook
- Define namespaces for caching e.g. for multiple views of the same page
- Auto Size content height in the grid row expander
- Add list support to grid column search menu via the additional config setting:
- Triggering Event option to locate rows by e.g. Refresh Rows Action
- Tooltips added to Form navigation buttons without labels
- Plus a number of other minor improvements and bug fixes
You can find more details about the above enhancements in the release notes here.