| Table of Contents |
|---|
Overview
...
Configuring the synchronisation is one of the most important parts of the Gantt widget, the changes being made within the widget are translated to your business logic for further use within you application.
...
The non-persistent entities should be mapped to your persistent business data model. This can be accomplished for Task, Dependency, Assignment and Resource. Within the entity TaskCrud there is an Action enumeration attribute with three values added, removed and updated. The three actions can be mapped accordingly (see example screenshot).
...
A Gantt widget is a complex component. One change can trigger a scala of updates. Furthermore You might want to rollback a change based on several factors. To allow this kind of behavior and to get around some of the Mendix pluggable widget API limitations the Gantt widget employs a custom sync. This has various implications. For one you do not need to refresh the entire list of objects just to refresh a single value in that list (which is the case for other Mendix widgets). As you can imagine, this greatly improves performance for large datasets. It might however take some getting used to so we recommend you take a look at our quick start application to see this in action.
...
The synchronization flow involves quite a few steps and we therefore highly recommend you start with our quick start application instead of trying to to build everything on your own purely based on the documentation.
...
The sync flow consists out a few steps:
First, all the CRUD objects will be created so they can be used to process the changes made in the widget in the further logic of the sync flow.
Second, the non persistable CRUD objects will be processed. These can consist of task, dependency and/or assignment objects.
Lastly a response needs to be given to the widget. This can contain several things. Like was the sync successful or should it be rolled back? What CRUD actions should be accepted and which should be rejected? What are the server id’s for newly created objects? See Error handling and rollback for details.
Syncing CRUD actions
...
Each individual list of crud objects (TaskCrud, DependencyCrud and AssignmentCrud) will need to be processed on the server. To do this you will need to loop over these lists and then split the subsequent action by it’s type (either updated, added or removed). Please see our quickstart application for an example on how to do this.
Sending server id’s back to the widget
...
When you’re dealing with a create CRUD action (or “added“) you will need to set the newly created id of the task, dependency or assignment on the CRUD object as illustrated above. This new server id will then automatically be send back in the response to the widget and be update there.
Error handling and rollback
...
The sync flow should always be ended by generating a sync response. This is done by calling the Java action “JAVA_Response_Create”.
Success will determine if a rollback of all changes should occurr
An optional toast message. If set a toast will be shown with any message you supply. If Success if false an error toast will be shown that needs to be clicked away by the user.
Finally the response will need to be set on the SyncResponse attribute of the gantt context object:
Rolling back individual CRUD actions
...
It’s also possible to roll back individual changes. This will revert the CRUD actions in question in the widget but will process all other changes.
Please keep in mind that some CRUD action might be required for the consistency of the model (e.g. changing the task start and end date if it has dependency to a previous task that forces the task to shift to the future). So use this feature wisely and sparingly.