Live Applications provide an API (view model + methods) for specific business cases.
All live applications are implemented in the Back End (Java), so all operations and calculations are made on server side.
- Applications are declared in a workspace for asset pages
- For each page provided only 1 instance of each type of page application is declared
- All applications which are declared on an asset page are available for all widgets on that page
- Every application provides a specific View Model implemented in the application
- Every application provides methods implemented in the application
- Applications notify the client about changes/updates in the View Model and the available methods
Getting updates from Application
|
applicationReader
- Instance of the csReaderupdateData.version
- The version of the update. It’s recommended to check if there are changes in update;updateData.data
- Contains the View Model of the applicationupdateData.methods
- Contains the application Methods, which are available in the current update
Calling Application methods
Example 1
|
Example 2
|
- All methods return a promise
- The input parameter can be passed to the method
- The
data.result.data
contains the output parameter if there is one - If the model was modified by a method call, the client will receive an update
- A method promise is rejected now when there is a
data.result.errorCode
. No need to check it now in the success function - Good practice: check if the method exists before the call
- Every application provides default application methods:
checkout()
- Available when the user is allowed to checkout an asset and the asset is not checked outcheckin()
- Available when an asset is checked outabortCheckout()
- Available when a user is allowed to abort checkout and the asset is checked out
- If the application method is called and it’s currently processing, then it’s in progress (a method promise was not rejected or resolved), other methods are not available.
Advantages and disadvantages
- Easy way to operate with asset and dependent assets
- Sharing one instance of application between all page widgets
- Provides a dedicated View Model
- Allows to get updates for opened and dependent assets
- Provides a built-in functionality regarding the check-out / check-in state handling (required for all editor pages)
- It should be added to the workspace manually
- All applications are alive while the
pageInstance
is alive. When alot pages are open then many applications will stay in the memory - There is no possibility to prepare the View Model object for the item-renderer. Additional asset queries must be executed by the Front-End
- Back-End development required